携程为什么突然技术转型从 .NET 转 Java？
作为携程在职员工谈两句。 我就是现在.net转java的一线的员工，是携程某BU后台开发人员。 先说说我们组转java的情况，我们组现在三个关键服务一个已经完全转java（.net服务还在线，但是新需求不更新了），另外两个核心服务已经在转java的过程中，部分接口已经在生产环境上线了。而新的服务全部是java写的。 先介绍一下携程老的.net环境。携程很早之前就打造了自己基于.net的SOA服务（当时还没有微服务的概念），在当时还是能满足携程的需求的。但随着携程业务的快速发展，特别是15年之后与去哪业务的整合，负载愈来愈大（稍微说一下，负载不仅仅是访问量的增长，还有很多产品提的需求，携程的业务是在太TM复杂了。。。。）。成本最低的是升级SOA框架，往微服务靠拢。这样业务代码就不用大改。但是！但是！但是！携程原来作为一家以业务为重的公司，代码质量真的是呵呵了，与其改动SOA，在重构老的业务代码，还不如推翻重来。（省略各种吐槽） 我是很支持鞋厂转型java的。主要原因有： 1、我不知道有谁用.net打造了一套高效的微服务架构（有了解的欢迎补充），而基于java的微服务架构已经有很多，技术风险低。而且java的整个生态真的是比.net好很多，特别是在国内，不要说在国外c#有多流行，我们是在中国。 2、在14年就开始有部门推动java的使用，但最高层抱着口头鼓励的态度，框架部门也做了很多支持。但是很多大BU，特别是机票在.net上已经付出了很多，也取得了很多成果，所以转型动力不足。转折点就是收购去哪，不得不承认，去哪在当时技术能力上是要比携程强的，所以现在携程很多技术是在学习去哪的。随着新CTO的到来，从最高层开始推动java转型。所以说扯什么政治斗争的我认为是在瞎扯，新CTO是来推动java转型的，而不是因为新CTO才开始java转型。 3、人力。很多人都提到了，java程序员好招人。携程从16年开始技术人员快速增长，要是都招.net，还不逼死HR？ 4、技术氛围。原来携程很多老程序员的水平是真不怎么样，而转型java也算是一次筛选吧。连.net转java都做不到，可想而知水平如何了。而且在转java的过程中，整个携程的技术氛围真的是越来越好的，很多人都开始拥抱新技术、新思维。go、python、ruby也在一些非核心应用上得到使用，发布系统也提供了支持，这在.net时代是很难想象的。 5、代码重构。刚才说了，老代码的质量很差，转java是一个非常非常好的机会去进行重构。我现在除了写需求，就是在考虑重构的问题，特别开心。毕竟作为有技术追求的人来说，只写需求太痛苦了。重构不仅仅是代码的重构哦，还有很多架构上的改变，具体就太多了，不详细谈了。 6、整个技术环境的改变。在转java的过程中，不仅仅是把.net代码转成java，而是加入了很多新的概念、技术。sonar代码质量检查、大规模的自动化测试、以docker为代表的运维的升级等等。可以说，转java是携程从业务驱动向技术驱动的一次转变。（广告打得不错吧，老板给点奖金不？） 总体来说，我双手赞成携程转java的，至少从我们BU看来，18年初主要业务将会迁移到java，集团的要求是18年底70%以上的业务迁移到java。现在转java的最大的难题已经解决，各个部门转java的进度已经加速。真心希望携程能通过.net到java的技术转型，能够改变大家对携程技术落后的印象，毕竟携程已经从30亿美元的公司成长为300亿美元的公司。当然，在转型的过程中，踩过很多坑，解决了很多问题，我收获了很多，为可能跳槽、加薪做好铺垫（为了这句话，我匿名了。。。。）。 ---------------------------------在下面说明一些评论区的问题---------------------------- 1、我不想争论现在.net和java谁好，我想说的是原来携程.net很一般。这个原因有很多，一方面是原来的人员水平不行。携程到今年也18岁了，和BAT都是一个年代的企业，10年前国内的软件环境真的和现在差很多，人员的平均素质也差很多。而且携程当时规模也没那么大，对技术的重视程度也不是很高，就导致技术人员的工资待遇相比较其他互联网公司有差距，那么人员的平均水平就可想而知了。但是15年以后对技术的越发重视，工资也达到了互联网圈的平均水平，甚至更高一点，所以吸引来的大量人才，整个技术团队规模扩大了一倍左右。 另一方面就是，原来的老系统在刚开始没有经过良好设计，现在好多年过去了，都是在修修补补，架构上问题很多。我们早都有重构的想法，但是现实情况是，每天都有新需求不停的提出来，重构需要很长的时间，无论是员工还是领导，为了kpi的压力没有动力去重构。而转java就是一个重构的机会，转java的时间能够充裕到我对老系统进行彻底的重构。 2、携程转java不是简简单单把.net代码翻译成java。在这个过程中，除了重构，还有很多技术架构的改变，比如有了代码质量检查和自动化回归测试，来解决代码质量较差的问题。在架构上也把原来很重的soa服务拆解，迁移到java服务。并且利用es,redis,消息队列等技术来提高效率，原来这些东西也有，到现在基本每个组都在用。有了java技术架构委员会，成员都是架构师，深入一线来解决问题，提供建议。所以这不仅仅是一个改变编程语言的问题！ 3、评论区一上来就满嘴喷shit的评论直接删，不解释，看着不爽! 4、 @肖进 给我介绍了一个C#的框架，我看了一下，性能确实不错。但是，我的观点认为：这套框架不太适合大的互联网公司，原因就一个，这个是框架是闭源的。主要原因如下： （1）在大公司采用闭源系统是有风险的，以互联网巨头的规模在这里，很多框架都会遇到坑，采用闭源系统意味着，你很有可能不知道造成这个坑的原因是什么，而且也很难修复。而且你也无法控制闭源系统升级的周期和走向。微服务作为现在一家互联网公司最核心的系统，反正据我所知，没有哪家互联网巨头在核心系统采用闭源框架的。 （2）这套框架主要包括RPC，视图层以及内存索引。这些部分离一个完整的微服务平台差的还很远。我在下面给出了现在开源世界最流行的微服务框架Spring Cloud，可以将两个框架进行对比（虽然我更加认同Spring提供了一整套系统，一个完整的解决方案）。一个微服务系统起码要包括服务治理，RPC，负载均衡，一整套监控系统，预警系统，错误处理（服务降级、熔断），Log系统等。携程作为一家比较大的互联网公司，很多系统已经有了，比如监控系统、日志系统（日志系统绝不仅仅是把日志记录下来）、负载均衡系统、服务降级系统、熔断系统。一套闭源怎么和现有系统对接？ Spring Cloud 基于以上原因，我认为这套系统不会满足携程的需求。怕人歪曲，我想强调，以上是我的个人观点！