微服务系统设计的五大挑战
【摘要】谈到微服务平台的建设，我们通常首先会想到的是容器编排和服务治理。但是在实际的生产过程中，即便是提供了容器云平台和微服务框架，微服务系统设计的门槛对于开发人员来说还是比较高的。总结起来，最主要的有五个方面。
【作者】金果，IT从业十五年，在多家大型IT企业从事开发、架构和技术支持工作，熟悉高并发分布式系统设计、微服务和数据库。目前在某银行从事基础架构和微服务相关工作。
随着移动互联网的发展和应用云化的普及，微服务已经成为企业应用服务化架构最流行的设计理念。随着银行Fintech的推广，越来越多的银行应用系统已采用或是计划采用微服务架构进行应用设计。以微服务、容器、DevOps等为支撑的云原生设计理念，缓解了随着新需求的不断增加的大型单体式应用变更越来越困难与移动互联网时代要求企业能实现应用功能的敏捷上线的矛盾。
微服务是一种架构设计理念，包括了通过服务实现应用的组件化的架构(Componentization via Services)，围绕业务能力组织服务(Organized around Business Capabilities)，产品而非项目模式(Products not Projects)和演进式的设计(Evolutionary Design)等实践和方法。
微服务推行的方式
在采用微服务时，我们对业界和企业的现状进行了调研。总结出两条可套的采用方案。
第一个是演进式方案。这个方案是在现有的应用架构上进行演进化的改造。在演进过程中，根据应用的实际需求，逐步的引入微服务的组件，最终实现微服务平台的搭建。这种方式是最早采用微服务的互联网企业的方式，优势很明显，搭建的服务平台是按需定制的，微服务的文化也随着演进深入企业文化。适用于规模迅速膨胀的初创企业，例如当初的某打车平台。而且对企业的自动化测试和持续交付能力有一定的要求。
第二种是服务平台建设方案。这种方案是参考业界的微服务最佳实践方案，建设支持微服务应用架构的服务平台，通过平台的试点项目的示范作用，在组织内部推动微服务化改造。微服务平台通常包括服务治理框架，开发框架，容器，部署发布和日志监控工具等。平台可以有效降低微服务开发的门槛，提高开发效率和开发服务的质量。
服务治理框架是微服务平台的重要功能。微服务治理框架可以解决的是微服务引入的额外的开发和运维复杂性问题。目前业界有很多成熟的微服务治理框架，比如Spring Cloud、Dubbo、Service Fabric，以及更新的Istio。这些治理框架更有侧重点，实现方式也各不相同，但是主要解决的问题是一致的，就是解决单体应用在拆分成大量微服务之后，服务与服务之间，服务与外部之间的服务发现，负载均衡，异步同步通信问题，以及监控和故障自愈等。基于Java的微服务框架中，Spring Cloud依托Spring的生态，功能上最为齐全。新一代的Service Mesh框架中，Istio依托Google的背景，是目前最接近生产应用的服务网格方案，当前版本还有不少问题需要解决。
根据我们的了解和调研，对于银行这样的大型企业，由于系统多分工较细，不同部门对新技术的理解和接受能力不同，采用第一种方式进行建设的时候，容易出现技术分化，就是组织内形成多种完全不同微服务平台技术栈，这些平台采用不同的协议和接口，需要在对接上花费大量的资源，不利于内部服务的打通。
平台和框架之外的问题
通过建设微服务平台，引入现有的成熟的微服务解决方案，平台和框架提供了微服务应用开发、运维的基础环境支持，是企业在内部快速的推广和实现微服务的一条“捷径”。微服务平台的建设，我们通常首先会想到的是容器编排和服务治理。但是在实际的生产过程中，我们发现即便是提供了容器云平台和微服务框架，微服务系统设计的门槛，对于开发人员来说还是比较高的。总结起来，最主要的有以下几个方面：
1.微服务框架对应用设计有特殊的要求，学习成本高
微服务属于分布式系统，分布式系统由于需要实现跨进程，甚至的跨网络的通讯，就存在各种各样的不确定因素，比如目标服务不存在，服务没有准备就绪，网络不可达，网络闪断和网络延迟等各种各样的问题。很多微服务框架，比如Spring Cloud Netflix和Istio，实际上就是为我们封装了跨进程调用的复杂性。这些框架一方面降低了编程的难度和提高了应用的容错能力和可靠性，一方面也是个应用开发的陷阱。对跨进程调用的良好封装，会对程序员造成一种假象，远程调用和本地调用是一样的，忽略了远程调用的成本和可能的问题。举个例子，在一个微服务应用中，发现性能非常的糟糕，最后发现其中有一个服务，依赖于一个外部的服务，这个外部服务是异步的，由于对其做了封装，导致上游服务都是按照同步调用的方式进行调用，导致大量请求的等待。再比如，我们都知道，在分布式系统设计中存在这有名的CAP原则（在分布式系统中，一致性、可用性和分区容忍性不可以兼得），很多开发人员开发时，没有足够的重视，导致数据丢失或是系统出现脏数据，甚至是数据不一致导致的系统漏洞。这些实际的例子都说明了，微服务的程序设计需要有相应的积累，形成规范和案例，为后续开发提供规范指导和能力培训。
2.微服务的拆分，是个很大的挑战
这是在微服务实践中遇到的最多的问题，如何对微服务拆分才合理，微服务的服务多大才算是微服务。微服务拆分是一个很大的话题，展开可以写另外一篇文章。这里只举几个例子和我们踩过的坑，和大家一起分享。第一个最常见的误区是划分服务的时候，按照业务流程的步骤进行划分，这是开发人员传统的面向过程的思维定势造成的。也可能是传统的SOA过度而来的一种划分方式。这种划分微服务的最大缺点在于，服务与服务之间存在很强耦合性，服务的优雅降级无从做起，而且还存在大量的跨机事务需要解决。另外一个问题就是基础功能或是公共代码的问题，开始采用微服务架构时，很多项目喜欢讲基础功能独立成为一个服务，这些基础功能不是业务功能，而是一部分公用的非独立的功能。在项目的初期，这种设计确实是提高了代码的复用，但是随着系统需求的变化，这些基础服务会被频繁修改，导致变得复杂难以维护。这种为了实现代码共享的基础服务，破坏了服务自治的约束，提高了部署和运维的难度，降低了系统的可用性。
3.微服务的架构，大大增加了服务之间的对接，沟通成本太高。
微服务将以前的内部接口升级成了服务接口。由于微服务的服务接口不仅在数量上大大的增加了，而且变更的频率也快了，传统的接口文档的方式，很难满足微服务的需要。导致接口变更困难，沟通成本上升。一些项目自己总结出一些好的经验，就是通过自动生产API描述文档的方式，解决了部分的问题，后续通过建立微服务平台的API治理平台和治理规范，进一步规范了API的定义和变更。在这个过程中有的项目也尝试通过公共代码库（或是公共lib库）来解决服务端客户端接口（Request，Response参数），也会导致服务端和客户端的强耦合，在大多数情况下，我们不建议采用这种方式。
4.容器和微服务，带来的开发调试成本提升
在完成我们的容器云平台和微服务治理框架的建设后，在实际的开发过程中发现事实并不是像我们想象的那样——开发人员可以像开发单体应用一样，快速的开发微服务应用了。应用的开发，测试和部署上线都与平台之间还存在着“最后一公里”的问题，不能流畅的对接。容器平台，特别是基于Kubernates开源搭建的平台，对于传统的开发者，并没有像宣传的那么友好。开发人员不只需要为每个项目编写Dockerfile，有些时候还需要自己搭建基础镜像。而这些数量众多的非标的基础镜像，在安全性和可维护性上，都存在着很大的问题。对于应用开发人员的不友好，还表现在本地环境的搭建上。由于Kubernates和微服务框架，特别是基于服务网格技术，很多功能都依赖于底层的平台。应用开发者需要进行调试和验证是一个复杂而且耗时的问题。
5.缺少架构标准和规范，导致架构风格不一致
这种情况在演进式微服务推行的方式下最为明显。架构风格不一定是一个缺点，由于不同的技术侧重点不同，有时多种架构风格是必须的。架构不一致最大的问题是资源的浪费和对接的成本。在异构系统的灵活性和维护成本上进行权衡，是每个架构管理团队需要进行权衡的。
经验和建议
以上提出的问题，在实践的过程中，总结了以下的建议，可以参考：
1、平台就绪：在容器平台和微服务框架之上，提供一个开发管理平台。开发管理包括以下的能力：契约管理、打包管理、部署管理、代码工程管理（内部的Start.spring.io），应用架构管理和CI工具自动对接等。让微服务研发过程可视化、工具化、自动化，让管理者能够实时管控和规范微服务研发过程。
2、微服务实施能力就绪，包括认知能力、技术能力，交付能力：项目在上微服务架构前，需要进行相应的培训，避免由于不合理的设计，导致生产问题。培训的内容可以是业界的优秀实践，比如12 Factors的云原生开发建议，也可以是开发过程中的案例。
3、建立和微服务相对应的小团队机制，控制团队的规模，根据团队的分工来划分微服务。微服务接口定义标准化，服务拆分按照业务逻辑拆分，服务之间架构合理，实现服务的弹性、自治、容错等能力。同时可以参考DDD（领域驱动设计）的一些方法来帮助设计。
4、避免过度设计，因为微服务而微服务。微服务是工具而不是目标。微服务是服务设计架构方法，微服务开发、运维、监控平台等是工具。微服务设计的目标是更好的支持企业业务应用的敏捷创新和变更需求。传统应用可以处理的技术问题，就不建议使用微服务。
5、实现容器平台上的应用热部署和远程调试。提高开发效率。
6、微服务治理和管理能力就绪
实现这几点去做微服务不会有大的问题。
结束语
技术是一个不断发展的过程，对于微服务和容器这些技术，微服务不是结果，而是一种工具。只有在实践过程中，借鉴已有的方案，形成自身的规范和标准。搭建用于帮助开发测试部署的工具平台，慢慢形成文化。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
推荐资料/文章：
微服务构建思路与方法论
http://www.talkwithtrend.com/Article/242631
微服务设计案例分析
http://www.talkwithtrend.com/Article/243423
微服务设计评估
http://www.talkwithtrend.com/Article/243497
欢迎关注社区 “微服务”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/95163
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场