提及中台，无人不知。从概念诞生于阿里到如今高居神坛之上，整个行业无一不在频繁建设中，不可否认，TA带来的ICT变革远远超过了字面含义。深入实践我们感受到，有了TA，业务架构清晰明了、需求响应事半功倍；有了TA，软件复用有规律、成本降低显而易见；有了TA，之前所顾虑的架构优化、稳定弹性等统统不再是问题……如此多的优点，充满对“中台”崇尚精神的远不止一两个，网易副总裁、网易杭州研究院执行院长汪源就是深信不疑的“其中人”。
但相比单纯的“崇尚”之情，汪源以及身后的网易云却有着属于自己的一套中台方法论。他表示，中台与平台有部分类似之处，都具备支持多个前台业务的共性能力；但存在差异的是，中台一定具备业务属性，而建设中台迫切需要三大要素，分别是承担业务职责的中台化组织、技术支撑和方法论，缺一不可。
其实网易云不单单深耕细作出一套建设中台的理论，如果从技术层面出发探讨，如今中台颇受关注，其背后的原因无非是对架构和技术变革的敏感度越来越高，对此网易云基础服务总经理陈谔更深入探究并提出，何种技术架构可以高效支撑中台而易见就是微服务。
不同于单体架构难以复用，不同于传统服务化存在性能、中心化管理人员的瓶颈，“微服务是一种去中心化的技术架构，不但可以解决服务细粒度拆分问题，还能够支撑高速迭代；但如果企业采用这种架构，就需要应对架构所带来的庞大复杂性，无疑这是一把双刃剑。”他说。
轻舟Service Mesh产品化，实现异构系统融合。针对在中台建设中经常会出现的异构系统整合和多供应商建设问题，网易轻舟微服务的最新技术升级恰好解决了企业的后顾之忧。作为围绕应用和微服务打造的一站式 PaaS 平台，陈谔坦言，针对异构系统的融合问题，网易轻舟微服务实现了Service Mesh开源技术的产品化。
据阿晶了解，Service Mesh是新一代微服务通信基础设施层，解决了多语言、多框架异构系统中服务通信、注册发现、治理等问题。陈谔进一步总结道，网易云落地Service Mesh将秉承几个理念：跟随社区，不重复造轮子；确保技术方案在生产实践中得到验证；开箱即用。
具体来说，轻舟Service Mesh（基于Istio、Envoy）产品化会根据客户需求进行扩展，并针对社区现有的短板进行改进，而不是简单的集成。例如Service Mesh社区版本仅支持容器环境，然而大部分企业仅实现了部分业务的容器化，所以轻舟Service Mesh实现了容器和非容器混合部署方案，支持容器、主机双向互通调用和统一治理。此外，轻舟Service Mesh不仅可以实现Java、Python、NodeJS、Golang和PHP等不同技术栈的兼容和通信，还能够与已有微服务框架NSF统一管控、互相发现、互相调用，将异构系统的支持实现到业界领先的程度。在性能方面，轻舟Service Mesh通过Mixer下沉，缩短路由路径，时延减少了50%。更重要的一点，据陈谔介绍轻舟的Service Mesh产品化已经在网易集团内部进行了大型生产环境的实践。
轻舟GTXS，高性能、低成本实现分布式事务。在采访中提及服务拆分，陈谔说：“通常微服务拆分有两种方法论，当然两种方法论是可以结合的。一种是从面向对象设计一路传承过来，领域建模的体系，比较适用于业务模型相对固定或者已经有一套旧系统存在，想完成系统改造的场景；还有一种则是重新构建系统，难度在于起初很难将模型准确无误建立起来，更多需要一种不断创新迭代的能力，但高速迭代的过程中，服务的抽象性不可避免会受到影响。所以，微服务架构其实可以重构，但需要有一套工具去支持重构，所以‘轻舟微服务’除了建模，还要注重重构的能力，这样才可以完成微服务的演化。”
细粒度微服务的成功拆分还不是终点，此时复杂的业务流程很难再通过数据库的事务机制来实现ACID特性，服务层面的分布式事务处理技术呼之欲出。对此，新鲜出炉的轻舟分布式事务框架GTXS，就做到确保微服务被拆分后，多个微服务在业务流程中的数据一致性，为企业微服务演化提供保障。
阿晶了解到，GTXS在保证性能的基础上，用户只需要为服务接口增加一行注释就可以完成分布式事务的接入，事务协调器单节点1700+TPS，这相比传统的采用TCC这样的模式效率提升85%。此外它全面支持Spring Cloud、Dubbo、gRPC等常用框架兼容以及主流数据库，支持TCC、事务消息等多事务模式；在监控运维方面还支持对异常事务进行回查、自动重试、手动重试等操作，异常事务监控报警可以快速帮助企业诊断问题，目前也已经在工商银行、网易严选等大型生产环境中得到了可靠性验证。
此外，我们知道在微服务架构中，API网关通常出现在企业系统的边界上，是业务系统和企业外部交互的重要桥梁。网易轻舟微服务基于Service Mesh技术，提供了全新的API网关，基于Envoy作为数据面Proxy，控制面引入Istio Pilot，与社区技术方向一致的同时，性能和扩展性得到了大幅的提升，还保留了原有网关的丰富的治理能力。
当天现场，陈谔还发布了成功落地微服务的全流程服务，覆盖DevOps最佳实践、可扩展性架构设计、微服务化拆分、治理建设、技术支持和高级运维等各个层面。通过全流程服务的保障，网易云可以能帮助客户从零开始构建自己的微服务架构，从而推进中台的建设。
此外，阿晶还列举了部分与网易云基础服务总经理陈谔畅聊轻舟、中台以及微服务的采访细节，可供开发者们深入了解。
1、阿晶：目前“中台”的概念很火爆，怎样的企业会比较适合建设中台
陈谔：首先选择中台建设的企业一般规模会比较大，因为这种体量才有能力去通过软件复用去支持前端创新等工作；另外，企业在前端层面应该要有创新迭代的需求，否则企业也不需要中台这样的设施。目前来看，大部分企业都十分重视数字化创新的工作，所以有中台需求的企业占比非常大，我们预计未来大约会有四分之一的大型企业会开展中台的建设。
2、阿晶：轻舟这波针对企业业务中台建设的升级，出于怎样的契机/u>
陈谔：轻舟最早推出的时候是支撑微服务架构的技术平台，在支撑客户的过程中，我们发现面向传统企业和互联网企业有很大的差别，例如互联网企业出现“巨无霸”业务时，通常直接使用微服务架构；而传统企业内部由于是单一系统，往往很难一步到位使用微服务架构，而是需要先将企业的能力进行整合，通过这种组合来产生新的业务，他的微服务是来自于方方面面的各个板块，我们发现这其实就是在建设一个中台。我们要对企业提供有效的支持，就要关注其最终的目的，企业的目的是建立中台，支撑其业务创新，而不是为了建立一个基于互联网架构的庞大应用。
3、阿晶：轻舟微服务主要在哪些层面来完成对业务中台建设的技术支撑/u>
陈谔：轻舟对于业务中台建设的支持，主要聚焦两个方面：首先是微服务架构的支撑，我们认为中台建设，底层一定是基于微服务的架构，这是核心的技术平台方向。在“微服务”架构方面，企业IT异构是最大的挑战，例如新开发的系统可能会涉及到不同的技术栈、不同的语言等，是很难扭转的。当然也会涉及到遗留系统的问题，比如遗留系统采用不同的协议等。所以轻舟首当其冲选择去发布了对Service Mesh的支持。
另外，是中台API管理以及服务的提供，毕竟将中台整体组织起来，最终还是需要对外提供服务的，甚至还会涉及到第三方开放接口等细节，所以API也是企业中台建设的重要方面。
4、阿晶：在为企业提供中台的技术支持过程中，轻舟自身的升级遇到了怎样的困难/u>
陈谔：一方面是企业自身的IT环境的复杂性，会涉及到支持多种操作系统、内核的版本，兼容各种协议、中间件等问题，这样算下来要消耗不少成本；更大的挑战并不是纯粹的技术层面的问题，还涉及企业支持中台建设的组织架构以及推进中台建设的职能设置问题。比如，企业在实施中台的时候，如果没有一个横向的组织者，底层的微服务技术栈会被拆为两半，运维部会说容器等基础设施属于我的职能范围，但不管上层的平台，这样的割裂会削弱微服务的效能。这时就需要架构师或者其他横向支撑的角色，来拉通两者的合作。
5、阿晶：您认为出色的企业级微服务平台需要具备哪些特征/u>
陈谔：出色的微服平台首先要保证系统业务入侵性很低，尤其是客户已经有很多业务，要进行微服务化改造或使用微服务的管控面，必须要保证很低的侵入性，否则企业根本无法使用；另一方面微服务平台的管控面最好与业务的运行时、技术栈实现松耦合，不能被强迫一定使用哪种技术栈或者运行时一定包含哪些组件等。总体来说，好的微服务平台是一种循序渐进的过程，而不是直接为企业提供了“全家桶” 来绑定，要视客户的发展阶段，视客户业务的复杂度，来提供必要的支撑组件，只有这样中台建设才会顺畅有序、物尽其用。
6、阿晶：关于轻舟微服务对于中台建设的技术支持，未来有什么迭代升级的计划/u>
陈谔：未来还有很多升级计划。比如，现在做的对Service Mesh的支持工作，其实也是为了适应企业异构的环境，但是Service Mesh社区版还存在着类似数据面性能的问题，这些都是我们后续要着力解决的。第二个，很多企业对高可用的需求并不亚于互联网企业，我们就要把同城双活、跨机房高可用的方案输出给他。第三个，还有自动化运维、智能运维程度的提升，因为整体来说运维成本还是企业建设中台、实施微服务架构所面临的重大阻碍之一，我们在可观测性、加速诊断效率等方面做了一些工作，使得整体运维代价降低了不少，但是还不够，所以我们希望能够进一步通过引入智能化的手段，提高整体的运维效率。
另外，对于企业来说，微服务应用跑在平台内，还会有PaaS、中间件等需求，单独去构建自己的数据库、缓存等服务对于企业来说也是一种运维的代价，所以我们有计划让我们的容器平台去支持PaaS。此外，还有类似企业级安全特性的需求，以及对AI的支持等。
7、阿晶：未来比较关注的“微服务”的技术点有哪些/u>
陈谔：未来比较关注的微服务的技术点主要还是集中在对Service Mesh的支持方面，毕竟Service Mesh带来的好处实在是非常多。比如网易内部，虽然很多业务已经实现了微服务架构，但还是有足够的动力切换到Service Mesh的架构上去。
比如说，有些业务会做“流量染色”的功能，使得流量能够顺利导向测试节点、测试库，但是之前需要为各种中间件、协议分别去做识别流量标签的工作，但在Service Mesh平台下，这些都不用做，在四层的流量直接去注入这个标签，用SideCar就可以把流量引导到需要的地方去。所以向这样一个先进的技术栈进化是非常有利的。
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8691 人正在系统学习中
来源：科技星象
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！