想不踩坑?快看4位大咖WOT分享微服务落地的正确打开方式!

【51CTO.com原创稿件】2018年5月18-19日，由51CTO主办的全球软件与运维技术峰会在北京召开。来自全球企业的技术精英汇聚北京，畅谈软件技术前沿，共同探索运维技术的新边界。而在本次大会上，除了众星云集的主论坛环节，12场分论坛更是各具特色，分别聚焦了时下最受关注的容器、AI、区块链、大数据、物联网等技术领域。

在19日下午的“微服务架构设计”分论坛现场，阿里巴巴技术专家徐冬晨担任本场论坛的出品人，她与58到家CTO沈剑、饿了么计算力交付部负责人李健、百度云资深研发工程师何方石分别给场内听众带来了四场精彩演讲，分享了微服务架构在落地过程的一些可行方案及实践思路。

58到家沈剑：58速运微服务架构解耦最佳实践

沈剑首先分享了58速运在业务开展过程中遇到的运维问题。据他透露，随着58同城业务持续的发展，数据量也随之慢慢提升。他们很快就遭遇了一个很有代表性的挑战——代码拷贝导致业务痛点。由于业务是逐渐增长的，在这个过程中，不同技术团队会有重复功能的需求，为了快速上线，不同技术团队之间拷贝相同代码，并在此基础上借鉴修改。这样带来的弊端就是，一旦原来的那套代码出现问题，其他所有拷贝的地方，全部都需要修改，因为这些拷贝的代码产生了跨系统、跨业务的耦合。

不仅如此，被迫联动升级也曾困扰过他们。由于数据量增多，访问量也随之增加，系统中的各个子系统时不时会出现问题，例如吞吐量过大、新增业务场景带来数据库读写压力、数据读取流程改变等等。渐渐地，底层复杂性不断扩散到上游业务层，导致业务层也需要配合修改。

最后沈剑和技术团队决定用微服务来化解这些困境。微服务化之后，所有业务侧都通过RPC像调取本地函数一样去调取远端的数据，至于这个数据是存在哪个数据库里，还是缓存里，都不需要关注，他们只需要关注服务层，当底层有升级的时候，所有业务线都不需要变动，只有服务需要升级。通过服务化，他们彻底解决了底层复杂性的耦合问题。

沈剑还给微服务架构设定了两条原则，第一条原则是数据库私有，任何上游不得绕过服务层去访问底层数据库，业务部门只能调用接口，通过接口去访问。第二条原则是对上游提供有限且通用的接口，并且服务层要保证无限的性能，确保可以解决业务部门关于吞吐量、访问量的问题。不过如此一来，服务层就会变得非常重要，沈剑建议将公司最基础的微服务化放在架构部，或者专门成立一个部门，由比较资深的技术人员负责维护。

改造之后，他们很快就享受到微服务带来的好处，例如加强复用性，消除代码拷贝耦合，屏蔽复杂性，消除复杂性耦合，而且还保证了SQL质量，可以给业务部门提供有限服务，无限性能。同时确保系统扩展性，消除数据库实例耦合。更重要的，调用数据更方便了。

但是微服务是一把双刃剑，有优势也同样有弊端。沈剑分享道，微服务也导致了系统复杂性上升，让层次间依赖关系变得复杂。与此同时，运维和部署更麻烦，虽然目前58速运计划在未来开发自动化的运维脚本和运维平台，但如果是小型的研发团队，微服务带来的运维压力可能会非常大。系统监控和问题定位也遇到同样的问题，变得非常复杂。“微服务，不是简单引入一个RPC框架，它需要一系列基础设施的支撑。” 沈剑总结道。

阿里巴巴徐冬晨：JVM- sandbox_稳定性体系的构建

徐冬晨认为，随着软件部署规模的扩大，系统功能的细化，系统间耦合度和链路复杂度不断加强。要继续保持现有规模系统的稳定性，需要实现并完善监控体系、故障定位分析、流量录制回放、强弱依赖检测、故障演练等支撑工具平台。出于对服务器规模和业务稳定性的考量，这些配套工具平台需要具备三个特点，即无侵入、实时生效、动态可插拔。

要实现这些，多少都会触及到底层技术——动态字节码增强。如果每个工具都自己实现一套字节码增强逻辑，前期实现的门槛与后期维护成本高，且不同工具间相互影响造成不可预知的风险。如何降低门槛屏蔽风险[鸢玮1] ，降低研发运维成本，同时又能支持上层多个工具平台功能的快速实现和动态管理，成为阿里集团的目标。在这样的背景下，JVM-Sandbox 诞生了，这是一套实时无侵入的字节码增强框架，它可以提供动态增强类指定的类，获取人们想要方法的参数、返回值和行信息;提供动态可插拔容器。

JVM—Sandbox能处理哪些问题呢?徐冬晨表示，它可以提供线上故障定位、线上系统流量控制、线上故障模拟、性能压测、录制回放、链路跟踪六大服务。徐冬晨列举了阿里集团内部的三个应用场景，一是线上故障演练，他们仅用1周时间就完成了故障注入部分的重构，在挂载效率和成功率方面有了明显的提升，缩短了演练的时间;二是依赖检测，利用JVM-Sandbox的模块容器的特性，阿里技术团队将前人开发的模块与新增模块一起挂载共同工作，完成依赖检测、故障注入等操作;三是录制隔离回放机制，即利用JVM-Sandbox的开发录制模块，和回放模块，实现线上录制线下回放，提高回归效率，拓展测试范围。

据徐冬晨介绍，JVM-Sandbox基于JVMTI技术规范，为观察和改变代码运行结果提供了即插即用模块接口的容器。而且还为AOP提供了一个新的实现方案——以插桩代替代理。“在工作中需要使用字节码增强技术，进行工具开发、实现业务功能的开发、测试的同学会非常需要它。”

饿了么李健：基于容器的混合云实践

李健介绍到，管理系统常见的一个场景就是混合云的管理，在饿了么业务快速增长过程中，资源规模增长也非常迅速，这也导致了服务器类型繁多，交付需求多样。为了满足业务的需求，让应用交付更为灵活稳定，饿了么想到了一个新思路，把物理资源抽象，对计算力进行标准化设置，统一对开发人员输出。如此一来，可以极大减少交付成本，而且标准化之后可以管理更多IT基础设备。

在经过仔细技术对比之后，饿了么选择了构建eleme[鸢玮2] 容器平台来实现应用交付。具体说来，eleme容器平台会交付三部分内容，一是客户应用部署，这个最常见，业务把应用交给开发部门，开发部门负责让应用实现，提供应用服务;二是标准服务一键交付，由于业务部门有很多团队，每个团队可能需要一套独有的环境来实现服务，但每个服务之间又需要建立联系，并且具有可复制性，这就要求技术团队必须提供标准服务，避免搭建复杂的运维环境。三是服务器的交付，即对外输出计算力。

构建容器平台离不开技术选型，李健认为，目前无论从生态还是活跃度来看Kubernetes(Google开源的容器集群管理系统)都已成为容器编排事实上的标准。“虽然企业在容器化时遇到的问题不可能完全一样，技术选型时可以根据实际情况选择，但脱离了标准往往意味着成本的大幅上升。”除了标准之外，李健建议技术选型还需要去重点考虑与自身业务的契合度、扩展性、生态发展、前瞻性。

那么Kubernetes落地户还会遇到哪些阻碍呢?李健透露，首先是容易遇到Pod(一个Kubernetes抽象，表示一组一个或多个应用程序容器以及这些容器的一些共享资源)重启方式的问题，因为Pod重启意味着新建一个Pod，之前版本就不再使用了，很多企业环境是无法接受这个设定的。

另外一个问题是Kubernetes无法限制容器系统大小，一旦有企业混合业务时，容量高达100G以上，系统会立刻报警提示磁盘已满。这就需要企业另行开发修改。

最后一个问题是DNS(域名系统)改造。很多企业都有自己的域名区域，并且希望能够集成到 Kubernetes DNS 的命名空间去，例如混合云用户可能希望能在集群内解析他们内部的 “.corp”，这就需要企业进行DNS改造。

百度云何方石：揭秘百度云函数计算实现细节

何方石在现场向大家揭秘了他和技术团队在百度云如何实现函数计算这个产品。函数计算实际上是一种无服务器的计算交付的产品，不需要引入任何框架，用户只需要在百度云的控制平台上或者通过API去编写自己的函数。函数编写完之后，百度云可以通过云端试点的触发器，或者API的调用来执行用户这段函数的业务逻辑。

那么人们可以利用函数计算实现哪些功能呢?一是无服务器后端，搭配HTTP触发器或API Gateway产品可以快速实现后端API，并无需考虑配置服务器与运维;二是实时数据流处理，从消息队列批量消费流数据，聚合、整理数据并生成指标，可以自动根据负载消费数据;三是IoT后端，与IoT Hub联动实现对IoT设备的管理能力，服务可自动调整规模，应对IoT设备增长;四是Cloud Native Connector(云原生)，基于event-driven(事件驱动架构)的云原生时代，云服务通过事件+函数计算互相打通，形成生态，更加灵活。

演讲最后，何方石将函数计算的特点归纳为“高弹性、低成本、轻量级、低延迟”。具体来看，首先它是一个高弹性的服务，其次它具有比较低的开发成本，再者由于云平台运行的是单一计算的函数，所以它具备轻量级的特色，最后是低延迟特点，一秒钟一次调用和一秒钟一万次调用的频率对比，延迟时间非常接近。

以上内容是51CTO记者根据WOT2018全球软件与运维技术峰会的《微服务架构设计》分论坛演讲内容整理，更多关于WOT的内容请关注51cto.com。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】

【责任编辑：周雪 TEL：（010）68476606】