很多朋友对于沪江英语网站源码分享合买和沪江英语免费课程不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！
DragonwellJDK最新版本8.1.1-GA发布，包括全新特性和更新！
导读：InfoQ发布《2019中国Java发展趋势报告》，反映Java在中国发展的独特性，同时也希望大家对Java有一个正确的认识。
2个月前，InfoQ英文站发布了一份《2019Java发展趋势报告》，从技术采用生命周期的角度，分析了Java这门20多年历史语言的发展现状。这份报告发布后，发生了几个我们没想到的问题：一是有些开发者对Java产生了深深的怀疑，有人表示“现在还值得深入研究Java吗？”，有人表示“Java已经落后别的语言好多年”；二是有人觉得这份报告不接地气，没有呈现出Java在中国的发展情况。
基于以上两个原因，我们决定策划和撰写这份《2019中国Java发展趋势报告》，要把Java在中国发展的独特性反映出来，同时也希望大家对Java有一个正确的认识：既不捧杀，也不要妖魔化。
毫不惭愧的说，这份中国区的Java发展趋势报告无论是参与专家，还是呈现角度，都要优于英文站的报告。专家来自阿里、腾讯、华为、美团、今日头条、小米、红帽…多家技术实践前沿企业，报告范畴不仅包括Java、JVM、JavaEE主流框架，还包括了各企业的Java应用实践访谈以及对Java趋势的点评。除此以外，我们还在InfoQ社区发起了Java开发者调查，把开发者的Java使用情况也如实呈现在本次趋势报告中。好了，话不多说，切入正题。
参与本次趋势报告的专家
杨晓峰，Java技术专家，OpenJDKCommitter李三红，阿里/蚂蚁Java技术负责人，阿里云智能资深技术专家小马哥，阿里巴巴ApacheDubboPMC和Spring-Cloud-AlibabaArchitect田晓亮，华为云ServiceStage首席工程师和ApacheServiceCombPMC单致豪，腾讯TARS开源项目负责人吴革，美团点评高级技术专家陈楚晖，红帽AppDev首席架构师，开源技术专家王石冲，字节跳动大数据工程师、Scala程序员张涛，Kotlin专家，Android技术专家，开源实验室博主黄飞，小米互联网商业部技术主管
Java技术采用生命周期概览
这张中国Java技术采用生命周期概览图是本次趋势报告的精华，结论来自于各位专家的判断。某些方面专家们观点出奇的一致，当然也有很多部分专家观点并不相同。可谓是金句频现、火花四溅。
技术采用生命周期划分方式
创新者早期采用者早期大众晚期大众
技术采用生命周期是美国高科技营销大师杰弗里·摩尔在自己的书《跨越鸿沟》里提出的概念。技术采用生命周期是一个用来衡量用户对某项新技术接受程度的模型，它认为一个新的技术，从一开始出现到最后走向成熟，必然会经历创新者、早期采用者、早期大众、晚期大众的阶段。
虽然每个人群间都会有裂缝，但是早期采用者和早期大众之间的那条裂缝最大，这条裂缝就是传说中的“鸿沟”，只有跨越过这条鸿沟，渗透到早期大众这个人群，产品才等于是进入了主流市场。
重要结论
1.Java13处于创新者阶段，Java11处于早期采用者阶段，Java8处于晚期大众阶段。
Java11将是未来Java用户的最可能选项；如果一个公司对大堆栈GC能力、延迟SLA等方面要求没有那么高，就没有足够动力去做相关升级，也未必有技术力量解决版本评估、兼容性修正等现实问题；Java新版本升级在中国的宣传还是不够，如果很多企业看不到技术升级的红利，势必也影响升级的积极性。
2.OpenJDK处于创新者阶段。
虽然国内很多头部厂商都在定制OpenJDK，但是目前定制OpenJDK被采用范围还都有限，主体使用还是OracleJDK（根据《JVM生态系统报告2018》调查显示，70%的开发者选择使用OracleJDK，21%的开发者选择使用OpenJDK）；厂商是否转向OpenJDK，还有一个重要考量因素就是看他们是否愿意付费使用OracleJDK，如果不是的话，未来OpenJDK可能会逐渐取代OracleJDK，目前国内头部厂商都在OpenJDK上有所动作；（对于参与OpenJDK的国内头部厂商来说，可能他们的看法更加积极，他们把OpenJDK定义在早期大众阶段）大家在公有云、私有云等方面的竞争格局，深刻影响着在OpenJDK上的竞争格局；OpenJDK很可能被认为是一种退?求其次的选择。
3.非HotspotJDK生产实践——GraalVM、IBMOpenJ9处于早期采用者阶段。
GraalVM目前还尚不可知其兼容性情况以及明确的商业化条款；GraalVM的部分技术，例如，基于Java语言开发的JIT引擎，可能会成为未来OpenJDK的基础技术；在国内，怀疑GraalVM、IBMOpenJ9进入普遍生产实践的可能性会比较低。
4.Lambda/Stream处于晚期大众阶段、VectorAPI处于创新者阶段。
Lambda语法以及StreamAPI也在开发人员的?常?作中?泛地运用，并且没有看到语法回退的趋势；VectorAPI等前沿特性，有能力的公司有限，抑制了对其有需求的公司或者场景。
5.Kotlin处于早期大众阶段，Scala和Groovy处于晚期大众阶段。
Groovy已快成为明日黄花，往昔的光芒逐渐地被后起之秀Kotlin替代；Scala在适合的领域做王者就够了，主流不主流没那么重要；Kotlin被谷歌强推，谷歌支持的基本上都成功了，但是对Kotlin未来发展空间还是表示怀疑；网上很多文章都在鼓吹，说Kotlin最终会取代Java成为新一代JVM主流语言，但是从诞生到现在，好像依然没有语言能取代Java。
6.微服务框架：SpringBoot和SpringCloud进入晚期大众阶段；ServiceComb处于早期采用者阶段；ApacheDubbo处于晚期大众阶段；Tars处于早期大众阶段。
微服务技术处于早期大众与晚期大众之间，新的微服务开发框架需要技术突破和创新，不然已经难有一席之地；Java不再是微服务唯一的选择；在技术多元化的今天，支持多语言的微服务开发框架是个必须品。
技术采用生命周期解读
在上一章节我们已经先把各位专家的观点和结论抛了出来，但是结论背后还需要很关键的原因解读，所以这一章节就按照Java/JVM、不同层次的主流框架、微服务这三个部分，来逐一呈现。
Java/JVM
其实在Java版本方面，各位专家的观点完全一致：Java13处于创新者阶段，Java11处于早期采用者阶段，Java8处于晚期大众阶段。
在InfoQ面向开发者的Java使用版本调查中，毫无悬念，在参与问卷调研的开发者中，88.7%正在使用Java8版本，这些人当中只有35%有升级计划，剩余65%并没有升级计划。
杨晓峰认为这一情况也正常：Java8在可预见的将来依然会是生产的主体，放在晚期大众阶段是合理的。但是对于很多头部厂商来说，Java11或者再后续版本，有可能陆续出现一定规模的生产化部署。他认为这样的趋势只会在头部公司发生，如果一个公司对大堆栈GC能力、延迟SLA等方面要求没有那么高，就没有足够动力去做相关升级，也未必有技术力量解决版本评估、兼容性修正等现实问题。所以结论就是：Java11处于早期采用者阶段。
对此黄飞补充：也正是因为Java11处于早期采用者阶段，因此相关的资料较少，遇到问题会有比较高的学习成本，例如JFR对11的支持，JMC对Java11的分析能力较弱。
而对于Java13，小马哥认为该版本在新GC算法的提升以及Socket实现上的变化还是非常令?期待的，因此Java13排在创新者之列。
对于Java的升级，Oracle宣布从Java9开始每半年将更新一个Java大版本——Java11是长期支持（Long-Term-Support,LTS）版本，Java9、10则成了过渡版本（non?LTS），因此，陈楚晖不建议用户在生产中使用Java9、10。在他看来，小版本升级相对风险是比较小的，而大版本变更则会有可能需要更改大量的代码，这也是为什么这么多人还在坚持用Java8，而不去更新Java11、12、或者13的原因。
对于开发者升级Java动力不足的原因，李三红的解释更为详细，他认为有两个原因：
敏捷的基础底层架构对软件升级的支持，企业对底层架构的重视程度也是Java升级的一个很关键原因。中国的企业业务发展都很快，但是其实很多对底层架构的支持和重视是不足够的。底层架构是否在企业内部被统一强管控，是否很容易支持不同软件版本的灰度，并能通过有效的预发测试，覆盖软件升级不兼容等带来的不确定性，这都考验着软件升级的难度。另外一点，如果企业享受不到技术升级带来的红利，包括性能、编程效率等多方面提升，势必也影响升级的积极性。
从此次InfoQ面向开发者的调研来看，对于目前Java的新特性和发展方向，56%的开发者认为可以解决当前的主要业务挑战，24%开发者的观点是不能。这也从另一层面表明：Java经常被吐槽演进太慢，但是业界对新版本的采用并不十分积极，这可能反映了Java/JVM发展与开发者的实际需求存在某种脱节。
OpenJDK定制版或者公开发行版
由于Oracle宣布2019年伊始，OracleJDK8以及更?版本在服务器端部署不再免费，因此OpenJDK就成为了大多数Java用户的选项。根据《JVM生态系统报告2018》调查显示，70%的开发者选择使用OracleJDK，21%的开发者选择使用OpenJDK。
陈楚晖也介绍了国内的情况：目前国内开发者使用最多的依旧是OracleJDK，其次是IBMJDK，也有部分企业采用OpenJDK。报告链接：https://snyk.io/blog/jvm-ecosystem-report-2018/
对于OpenJDK的技术采用生命周期划分，专家们有一些观点上的不一致，杨晓峰认为虽然国内很多头部厂商都在定制OpenJDK，但是目前定制OpenJDK被采用范围还都有限，这也跟上文数据结果吻合，所以他会把OpenJDK归在创新者阶段。
但是对于参与OpenJDK的国内厂商来说，可能看法更加积极。在李三红看来：厂商是否转向OpenJDK，还有一个重要考量因素就是看他们是否愿意付费使用OracleJDK，如果不是的话，未来OpenJDK可能会逐渐取代OracleJDK，目前国内头部厂商都在OpenJDK上有所动作，所以他把OpenJDK定义在早期大众阶段。阿里巴巴使用并开源了OpenJDK长期支持版本Dragonwell，目前阿里巴巴大部分的应用运行在Dragonwell8,有些已经运行在Dragonwell11。
据来自美团的吴革介绍：美团现阶段正在测试基于OpenJDK的MtJDK，作为美团JDK基础服务。此外，美团主要会关注Redhat和Amazon的升级。由于Azul没有公开OpenJDK源代码，所以美团没有基于Azul进行研发。
来自小米的黄飞也介绍了小米对于OpenJDK的应用情况：小米主要使用OpenJDK8以及11版本，目前对OpenJDK主要还是以使用为主。
从现有的OpenJDK阵营来看，目前分为两类，一类是IT和云厂商，他们对外提供发布、销售的OpenJDK版本——Amazon、Redhat、Azul、阿里巴巴、腾讯都在自己生产（除了微软分发Azul）；另外就是技术上的强需求导致自身有定制OpenJDK的公司，他们的OpenJDK产品较难突破内部使用的范围，比如我们采访调研的美团、小米。
对于这样的一个阵营划分，杨晓峰有一个观点：从OpenJDK发布版的竞争格局来看，最终会演变为云的格局，坚持下来的会是头部云厂商或与其合作的软件厂商。换句话说大家在公有云、私有云等方面的竞争格局，深刻影响着在OpenJDK上的竞争格局。毕竟对于企业来说，做OpenJDK也需要有利可图，没有广泛的用户群体和对等的收益，很难支撑基础软件的长期演进。
我们把以上观点抛给了此次调研采访对象——IT公司和云厂商阵营的代表李三红，在他看来：在Java收费的情况下，OpenJDK一定是大势所趋，Java会越来越开放，深度参与OpenJDK也是为了通过社区驱动Java往前走；另外，在当前企业上云的大趋势下，如果客户的现有系统是用Java写的，云厂商在为客户提供服务的时候势必要考虑如何让Java生态变得更好，这也是符合客户的诉求。
不过杨晓峰也表示：从企业IT决策角度来说，相当一部分企业更加看重的是长期可信的支持、及时的安全漏洞和bug修复等。也会有可观的企业会决定风险自负，直接获取免费、自由的OpenJDK发行版，并不会购买支持服务，甚至不考虑升级JDK，直到今天JDK7等历史版本仍有可观的占有率，正是说明了这一点。
非HotspotJDK生产实践——GraalVM、IBMOpenJ9
GraalVM被列为早期采用者阶段，对此李三红表示：GraalVM已经在OracleCloud生产环境大规模使用，TCK兼容。值得一提的是，GraalVM下的静态编译SVM造成了Java语言一些方面的不兼容，这个也是整个社区担心的地方。如何让SVM/静态编译能纳入到JavaLanguage/JVMSpecification里来？值得关注。
杨晓峰的看法更加极端：在国内，怀疑GraalVM、IBMOpenJ9进入普遍生产实践的可能性会比较低。怀疑它们可能不会再走到下个阶段，很难跨越技术鸿沟。提及原因，他认为主要是国内公司大都在强调业务创新的速度，没有做如此深度的底层更新的耐心和业务必要性。而且从技术上来看，在动态特性支持等需求没有平滑解决方案之前，迁移难度很高，会带来很高的开发和运维成本。
所以对于国内普通企业用户来说，没有单独关注的价值。未来更加现实的技术采用路径是，用户使用集成了GraalVM先进技术的OpenJDK主分支。同样，IBMOpenJ9有很多独到的技术，如果能够合并入OpenJDK主分支，更能创造普遍的生产价值，否则难免会被局限在IBM中间件等用户群内部。另外，订阅GraalVM服务的具体信息可能在今年CodeOne会有说明，大家有兴趣可以关注。
Lambda/Stream、VectorAPI等语法与特性
对于Lambda/Stream等语法与特性，采访调研专家认为应该归类在晚期大众阶段。小马哥认为这些语法与特性在开发人员的?常?作中?泛地运用，并且没有看到语法回退的趋势。吴革表示：在美团内部，目前已经大量使用Lambda和Stream表达式。
而对于VectorAPI等前沿版本特性，杨晓峰认为还只在个别头部公司处于原型阶段，应该被归在创新者阶段。
Kotlin、Scala
对于Kotlin和Scala，我们也采访调研了两位Kotlin和Scala领域的专家。
在今年5月份的GoogleI/O大会上，Google官方正式宣布：Kotlin是Android应用程序开发人员的首选语言。这是否意味着Java占据Android开发绝对统治的时代一去不复返了？
虽然身为Kotlin专家，但是张涛的观点还是很理性而客观的，他表示：每几年都会有语言号称要取代Java，但是从诞生到现在，好像依然没有语言能取代它。这主要源于Java在服务端的稳固地位，没有语言能够做到Java这样完善的社区、用户群和三方库支持。
张涛认为：Kotlin在国内应该处于早期大众向晚期大众过渡阶段，在未来一两年内，会有大部分的JVM平台开发者开始使用Kotlin。
在2017年年底，张涛曾经做过一次调查，邀请将近1000名Android开发者，了解他们的项目中是否使用了Kotlin。当时的结果是30%的人使用过Kotlin，60%的人听说过Kotlin，还有80多人没有听说过。他相信目前国内的Android应用应该90%都包含有Kotlin代码。
此前InfoQ曾对字节跳动大数据工程师、Scala程序员王石冲以及另外几位来自Scala社区的专家进行过一次访谈，了解Scala在国内的发展情况。对于有人认为的Scala难成主流的说法，王石冲表示：Scala为什么非要成为主流呢？它在自己适合的领域做王者就够了，主流不主流其实并不是那么重要。
王石冲把Scala归在早期大众或者晚期大众阶段：Scala在可预见的未来都会是小众——有一少部分人非常喜爱它；有一少部分团队或公司在使用它；大部分人最多只是听说过它而已。Scala无论是在国内还是在国外，都称不上是主流语言。不过有部分团队水平很高的公司，还是深度应用Scala来做事情。
成名的例子就有Twitter、LinkedIn、Verizon等。金融行业则有摩根士丹利、渣打等（但是他们作为闷声发大财的典型，很少对外宣传自己的技术选型）。而很多硅谷的初创团队早期为了快速开发，也是采用的Scala。在国内，除了小米、阿里和腾讯的部分团队以及类似于GrowingIO、水滴这样的初创公司和一些广告公司外，大部分开发者都是应用Scala来做Spark开发。因为没有典型的、具有号召力的大公司主导，所以Scala在社区方面做得也一般。
SpringBoot/Cloud、ApacheDubbo、TARS、ServiceComb等微服务框架
对于微服务框架的技术采用生命周期的划分，我们分别采访调研了阿里、腾讯、华为等几家大厂的专家，这几家大厂都拥有各自的微服务框架解决方案。不过微服务框架的王者依旧非SpringBoot和SpringCloud莫属，对于这一点大家也达成了共识——SpringBoot/Cloud处于晚期采用者阶段，拥有大量用户。从InfoQ此次面向开发者的调研来看，选择SpringBoot/Cloud的开发者占到70%；其次是ApacheDubbo，占到20%；其他微服务框架的占比都还不太高。
田晓亮表示：SpringCloud社区依然在蓬勃发展，也开始为云厂商创造商业机会，如何与SpringCloud结合，成为了云厂商要解决的关键问题之一。
虽然越来越多的企业选择了ServiceComb进行微服务转型，并获得了成功，但并未普及到早期大众阶段。ServiceComb中微服务框架与ServiceMesh可以融合使用，让用户有了灵活的选择。
Java依然是最流行的语言，但企业也终于能够选择其他语言进行微服务开发了。同时提供SpringCloud的组件可以使其接入到ServiceComb中，帮助SpringCloud用户平滑向多语言转型，Java不再是微服务唯一的选择。
ApacheDubbo一开始并不叫这个名字，Dubbo一开始只是阿里内部的一个系统，2010年Dubbo项目进行重构，2018年初，Dubbo项目正式进入Apache孵化器。在小马哥看来，ApacheDubbo属于晚期大众阶段，不过最新的ApacheDubboECOSystem（生态系统）则是一个基于ApacheDubbo衍进的CloudNative解决方案，目前尚未枝叶茂盛，处于创新者阵营。
对于ApacheDubbo，黄飞表示：它在RPC中间件这个领域可以算得上引领者之一。ApacheDubbo的服务注册与发现、服务治理相对完善，支持灰度发布，智能的负载均衡策略、可视化的服务治理与运维工具便于开发人员上手。可以说Dubbo/Dubbox在RPC框架/微服务领域已经展露头脚甚至在某些方面已经形成优势。
TARS在腾讯内部叫TAF(TencentApplicationFramework)，是腾讯应用产品最多、最广泛的微服务开发框架，并且已经在腾讯大规模应用了超过十年。2017年中旬，腾讯正式将TARS开源，开源后一年便成为Linux基金会开源项目。由于相对其他微服务项目开源晚，错过了很多社区发展红利。
对于TARS，据单致豪介绍，不同的微服务主流框架可以满足不同的应用痛点，TARS则原生专注多语言和高性能。他认为TARS已经有大型互联网公司广泛使用，已经从早期采用者阶段迈过了鸿沟，进入了早期大众阶段。
Java应用实践
InfoQ：您的企业使用的JDK版本情况，是否采用了某个OpenJDK发行版？您如何看待OpenJDK在国内的发展？（如果没有采用，原因以及后续计划？）
阿里巴巴李三红：目前阿里巴巴大部分的应用运行在Dragonwell8，有些已经运行在了Dragonwell11，我们正在逐步推动从Java8到Java11的升级，充分享受技术红利。
美团吴革：美团现阶段主要使用Java8，很少一部分是Java7。部分核心团队正在尝试Java11。在美团内部采用的开发版本JDK主要还是OracleJDK。我们在服务器上的JDK版本主要是美团自己的MtJDK和OracleJDK。美团现阶段正在测试基于OpenJDK的MtJDK，作为美团JDK基础服务。
MtJDK主要基于OpenJDK构建，现阶段主要针对补丁和安全性进行维护。现阶段在特定业务线内部进行测试和应用。未来配合Serverless等基础服务升级，MtJDK会在JDK启动性能和增强应用之间的隔离进行深度定制。
小米黄飞：小米主要使用OpenJDK8以及11版本。目前对OpenJDK主要还是以使用为主，主要的业务关注点在于这个版本是否为长期支持；是否有更加高效易用的特征，例如GC算法由CMS、G1升级到ZGC等；开源社区是否活跃；以及对遇到的问题是否有足够丰富的资料与讨论等。
Java作为使用最为广泛的语言，最近几年还是有比较大进步的，无论从语法的易用性上还是性能上都有很大程度的提升。吸收了函数式编程的思想，lambda表达式、Parallemstream、Var变量等提升了开发人员的效率与代码的简洁性。ZGC无疑是一项重大的改进，在一定程度上解决了Java天生的GC问题。
InfoQ：您的企业目前在支持Java技术栈方面的策略是什么？计划和目标是什么？相关的核心痛点或者业务需求是什么？
腾讯单致豪：腾讯内部占领导地位的开发者是C++，同时有大量的Node.Js、Golang、Java、PHP、Python开发者，当然也有少量的Rust、C#的开发者。我们在海量用户的后端大部分采用C++和Golang，Java在前端和大数据方面有广泛使用，在对外ToB的交付中也大量采用。
由于腾讯的开发者使用了多种开发语言，而且不同开发语言在不同领域有不同优势，所以当前要解决的问题是多语言开发的服务互通问题，一套支持多语言的微服务开发框架是必需品，TARS也是在这样的多语言背景下诞生。
美团吴革：美团的Java技术栈策略偏向稳定，在稳定的基础之上推动技术升级。Java核心痛点就是依赖升级，当一个jar包升级，必须一个服务一个服务升级，不能自动化整体升级，所以对于美团来说，正在解决相关依赖升级的问题。
红帽陈楚晖：红帽主要采用市场流行的Java技术栈。大部分的项目都会采用Java进行开发，主要是因为Java比较成熟，有很多成熟的技术框架可以直接使用，同时也有很多类似的代码可以重用，也比较容易找到熟悉Java的技术人员。这样开发的速度和效率会比较高，以及成本会比较低。
InfoQ：请介绍您的企业是否进行了微服务实践？如果是，在整体系统架构中的比例是多少？如果不是，是否有相关计划？
阿里巴巴小马哥：大多数应用已实施微服务架构，微服务应用的比重达80%以上。
腾讯单致豪：早在2008年以前，腾讯已经开始实践“大系统小做”的海量服务之道理念，大量的服务已经是遵循微服务理念开发。因为腾讯要支持快速迭代和敏捷研发，所以微服务比例占比在95%以上。核心业务模块因为要支持海量用户的巨大流量，100%都是微服务。腾讯内部使用TARS开发的微服务已经超数十万个节点，在规模上来看，是全球最大的微服务集群之一。
美团吴革：美团在2015年开始微服务架构演进，核心系统已经100%微服务化。
红帽陈楚晖：已经进行了微服务实践，在整体系统架构中占比不超过30%。
华为田晓亮：华为云的所有服务都采用微服务架构，但并非所有服务都用了某种微服务解决方案——比如ServiceComb，Istio或者Springcloud，各服务主要是自行实践微服务设计模式。但几乎所有应用服务都采用了华为云容器服务CCE(CloudContainerEngine)的kubernetes集群。
InfoQ：您所采用的主要微服务框架是什么？如何判断国内该领域的技术发展情况？您认为微服务主流框架的争夺是否尘埃落定？
阿里巴巴小马哥：2015年初开始，阿里巴巴集团的应用架构逐渐由SOA衍生至微服务，所使用的微服务框架主要以SpringBoot/SpringCloud和ApacheDubbo（HSF）为主，涵盖所有Java中间件核心基础设施、九成以上的内部系统，以及阿里云商户应用等。
同时，基于SpringCloudAPI，阿里巴巴衍生并开源出一套全新的微服务框架-SpringCloudAlibaba，并且正走向下一代“云原生”架构，越来越多的应用开始尝试Serverless以及ServiceMesh等前沿技术。相信未来微服务在不同语言和平台上将会提供更多的选择，至于那时谁是王者或主流框架，这个问题的答案已经不再重要。
腾讯单致豪：不同的微服务主流框架可以满足不用的应用痛点，比如SpringCloud、Dubbo专注Java领域，TARS则专注于多语言和高性能，充分发挥C++的高性能、Go的性能与高效兼顾、Java的全能、Python丰富基础库尤其是AI方面、Node.Js和PHP便捷全面为Web而生等等优势。
目前中国和美国大厂开源的微服务框架（腾讯的TARS、阿里的Dubbo、百度的brpc、谷歌的gRPC、Facebook的Thrift、Pivotal的SpringCloud）基本能覆盖所有用户的痛点，企业直接从开源社区选型能解决自己痛点的开发框架即可。
美团吴革：主要采用自研OCTO和Pigeon，现在正在开发ServiceMesh服务。现在国内主要是基于Dubbo、SpringCloud、GooglegRPC作为基础进行二次封装，主流框架选型已经相对成熟。
红帽陈楚晖：主要采用SpringCloud的微服务框架，也对ServiceMesh（Istio）有研究。由于现有的微服务框架需要开发人员过多的介入，需要有大量的开发，所以目前大家比较看好Istio。但是由于Istio还不够成熟，因此大家都还处于预研阶段。
华为田晓亮：华为许多的云服务和内部项目采用了ServiceComb的微服务解决方案，比如消费者云，在全世界运行着数千微服务实例来为手机用户提供服务。此外，华为云的音视频服务也运行着数千的微服务实例，来提供视频通话、音视频解码等服务。并且我们也向社区（通过ServiceComb）和商业用户（通过ServiceStage）提供解决方案。
InfoQ：您如何看待ServiceMesh在国内的发展现状和发展前景？
阿里巴巴小马哥：个?对ServiceMesh的看法是乐观偏谨慎的，一??，作为从业人员，对于技术总有猎奇的心态。另外一??，这个技术在设计上存在一些理想主义，比如，性能损耗以及稳定性，并且分布式场景中的典型问题并没有得到解决和改善，比如数据一致性、分布式事务等。
据我所知，国内不少的互联?公司，如阿?巴巴、蚂蚁?服以及美团等已经开始在生产环境试点ServiceMesh，听起来这是一件好事。前沿的技术总需要有?去探险，如果成功，前人栽树，后人乘凉。至于它能否成功，主要看市场是否愿意买单。
美团吴革：未来ServiceMesh会在跨语言场景下大放异彩。ServiceMesh主要是基于云平台和多技术栈场景下的痛点进行的开发，短时间内不会有爆发性的增长。但是基于原生云架构系统的增多，未来ServiceMesh会不断演进，最终变为云原生架构下的网络基础服务。
腾讯单致豪：ServiceMesh目前还处在早期发展阶段，其理念设计已经决定了性能及维护性上会是它最突出的短板。但有部分企业包括腾讯已经尝鲜，也有小量周边不重要非核心业务在上面跑。ServiceMesh有着优美的架构理念，但性能确实让人担忧，社区生态也至少需要三年以上的发展时间。
华为田晓亮：大环境来看，传统企业面临的挑战依然是业务系统如何向微服务转型，以构建自己的业务平台，在这其中微服务框架是一种手段。为了寻求更快速地微服务化，开发人员就会避免学习陡峭的开发框架，而转向使用ServiceMesh。开发者将结合轻量的SDK（例如对接监控系统、配置管理、AI平台，而不是微服务框架）与ServiceMesh来实现自己的业务系统，从繁重的架构工作中解放出来。这个发展历程在我看来大概需要2-3年的时间。
而且，在我看来，最终站上舞台的并不是ServiceMesh，而是底层由ServiceMesh提供支持的Serverless平台，用户感知不到ServiceMesh技术的复杂性，否则将面临比开发框架更繁重的基础设施运维挑战。所以ServiceMesh其实和Serverless的发展是绑定在一起的。Serverless的普及和使用必然会帮助ServiceMesh进行发展。
InfoQ：对于当前Java的整体发展情况，您有什么感想？
杨晓峰：在可预见的将来，Java依旧是企业软件、大数据、电商等等最核心的技术栈。但是目前Java/JVM能力在云时代有一定局限性，比如云里强调的无服务器、微服务等场景，Java/JVM都有一定短板。
另外Java新版本采用速度这么慢，本身就说明，Java创新和实际需求存在某种程度的脱节——一方面大量创新会带来兼容性和版本混乱的问题；另外创新带来的优点却需要极大增大开发运维成本，这也让部分创新的价值被抵消了。
但是Java会被取代吗？应该也不会，目前在社区、工具、类库等等方面，Java还没有真正意义的对手，但是最大的威胁是新的需求浪潮是否与你有关。我们可以看下GitHub上Java新项目的趋势，一定程度上可以佐证Java坚实的基本面和不可忽视的隐忧。
阿里巴巴李三红：从技术角度来看，Java（JDK）这二十几年的发展一直试图在Productivity以及Performance之间做最好的平衡。Java是静态类型语言，但是为了生产效率提供了大量动态的特性比如BytecodeInstrument、DynamicClassLoading、Metaprogramming(Annotation、Reflection等，这些形成了Java在运维、生产监控等领域的基石技术。
同时由于Java大量的动态特性存在，使得它在面向云原生、Serverless计算时MemoryFootprint、Startup方面被人所诟病。这也是整个Java社区，当然包括AlibabaDragonwell所试图解决的问题。
阿里巴巴小马哥：Java目前仍具在编程语言排?榜上夺魁的能力，不过在整体比重上微幅下滑。个?看来，未来这个趋势还将持续。究其原因，一??是由于新语种出现的中短期效应，一方面是Java的编程复杂度并没有明显的降低，比如I/O处理、并发/并?计算，以及类加载等等。再者是Java与操作系统之间的交互仍不够充分，尽管Java9开始提供了不少的API，然?了解和使用的群体不?。Java在这方面明显不及GO语言。
从语?层?来看，Java正在向主流非Java语?融合，解决其中鸿沟的关键是语法的变化，比如Java8的Lambda表达式和Java10的局部变量类型（var）等。个人认为这是一件好事，未来前后端不分家，相互渗透，对于彼此语言都是良性发展。
除此之外，个人比较期待的是GraalVM对Java的改变，传统Java应用必须依赖JVM进程加载字节码后解释执行，无法保证所有的代码能够在运行期编程完成，不免有运?时编译所带来的性能开销，从而影响JVM的启停时间。简单地说，这种方式不够Native，对于云原生或许不够友好。如果未来GraalVM的社区版也能够像OpenJDK那般“亲民”，那么，Java的变化将是颠覆性的。
美团吴革：当前Java已经发展成为一个庞然大物，语言上基本不会有太多突破，更多是借鉴和兼容。随着GC算法的升级和编译器换代，面对Go等新一代语言挑战，还有一战之力。
腾讯单致豪：毋庸置疑，Java语言依然活力十足，但在某些方面已经失去优势，如云原生领域现在出现了更具活力的Go语言。纷繁的世界必定会出现多语言并存、不断替代的现象。回顾历史发展进程，一种语言要从出现到早期大众使用基本都需要十年时间，能历经十年磨砺生存下来的开发语言，必定是有很强的生命力，而且都会有不同的企业构筑其生态。正如上文所说：不同语言也会在自己优势之处持续发展，形成很强的竞争壁垒。
字节跳动王石冲：Scala语言目前有两个大的目标运行平台——JVM和js，所以Scala作为一个语言和生态并不敢完全投资在单一目标平台上。虽然JVM本身在不断进步，但是Java已经被同平台的多种语言赶超，比如Kotlin、Clojure、Groovy。
报告参与者介绍
杨晓峰，Java技术专家，OpenJDKCommitter。
李三红，阿里云智能资深技术专家，2014年加入蚂蚁金服，现为阿里/蚂蚁Java技术负责人，有超过10年的Java开发经验。活跃于Java技术社区，在Java虚拟机领域拥有多项技术专利。
小马哥（@mercyblitz），《SpringBoot编程思想》作者、ApacheDubboPMC和Spring-Cloud-AlibabaArchitect。
田晓亮，华为云ServiceStage首席工程师和ApacheServiceCombPMC，7年云计算领域工作经验，在PaaS，混合云，DevOps，微服务，APM方面有多年的实践经验。
单致豪，腾讯技术委员会和腾讯开源办公室成员，负责微服务框架TARS的开源生态，并将项目捐赠Linux基金会。云原生产业联盟专家顾问，DevOps标准专家，GOPS大会主席团。
吴革，美团点评高级技术专家，现在主要负责美团点评小象事业部系统架构工作。
陈楚晖，红帽AppDev首席架构师，开源技术专家，熟悉多种开源中间件，长期就职于国际知名软件公司，二十年中间件工作经验，拥有丰富的电信运营商、政府企业、金融等行业的系统集成、IT项目管理经验，具有丰富的一线实践经验。
王石冲，字节跳动大数据工程师，Scala程序员。译著有《反应式设计模式》。主要专注于基于Scala构建的反应式架构以及相关应用的实现。之前在从事中小型企业的实时数据流分析系统的开发。第四届阿里中间件性能大赛优胜奖，第一届阿里云PolarDB性能大赛季军。
张涛，网名kymjs，Android技术专家，“开源实验室”博主，Kotlin技术推广者，四年前开始接触和使用Kotlin语言。带过团队，做过架构，写过应用，做过开源社区。曾先后在沪江、饿了么、携程工作，目前在一条生活馆负责移动开发管理工作。
黄飞，小米互联网商业部技术主管，在互联网商业化变现方面有丰富经验，负责小米互联网广告业务引擎与算法架构工程研发，在高并发分布式推荐系统有多年的实践经验。
特别感谢：感谢杨晓峰老师参与此次报告的前期策划，并在报告撰写过程中给予专业的建议和指导。
作者|张晓楠
本文为云栖社区内容，未经允许不得转载。
好了，文章到此结束，希望可以帮助到大家。