如何应对数千微服务组件带来的挑战？

高驰涛 (Neeke Gao)，PHP/PECL开发组成员，掌握近10种开发语言，9年架构师经验，6年研发管理经验。云智慧AIOps社区PMC，同时也是PECL/SeasLog、PECL/JsonNet、GoCrab等多项开源软件的作者。2014年加入云智慧，致力于APM与大数据产品的架构研发，崇尚敏捷、高效。

从一个问题谈起

从几年前某CTO的一个问题说起：“我们的系统将会拥有5000个微服务组件，我们应该怎么做？”

我们都知道一个接口是无法称之为微服务的，接口数量达到十几个或许才够称之为微服务。那么，对于包含5000个微服务的系统而言，该如何实现和管理呢？

在这样庞大的系统背后，可预见的一定存在很大的问题。

微服务的前世今生

微服务是如何诞生的，必须了解以下四个领域：

TOGAF：全称“开放组体系结构框架”，TOGAF在上世纪七、八十年代的时候就已经由专门组织负责开发了，直到1995年美国国防部参与之后，TOGAF才最终成型。

如今，大家手机里正在使用的产品和应用中，很多都会用到SAP、IBM或者惠普的软件，而这些软件公司所遵循的就是TOGAF。可以说目前全球超过50%的企业正在使用TOGAF实践软件架构设计和开发。

TOGAF是一个架构体系，但并没有提供具体的架构方法。TOGAF包含了业务架构、应用架构、数据架构、技术架构等。

TOGAF有三个最为主要的支柱：

企业架构域，主要是企业信息与业务流等； ADM一系列的架构方法论； 企业连续性，指的是在企业业务高速增长并且不断变更的过程中，保证架构体系的连续性。

DDD：全称为“领域驱动设计”，其包含了诸多的概念，三句话进行概括：

DDD是精简的业务，DDD首先关注的就是业务，把各种繁琐的业务流程精简成更细的链条； DDD需要回答业务是干什么的，能够满足什么需求，达成什么目的； 不断迭代，DDD的不断迭代与TOGAF的企业连续性类似。

SOA：全称为“面向服务架构”，理论同样较多，总结为以下三点：

SOA解决了信息孤岛的问题； 业务重用，从业务角度将各个服务组合成一个个中间件或者服务，将其提供给用户或者其他系统； SOA使得系统成为互联互通的信息群。

GRASP原则：全称为“通用职责分配原则”，包含很多耳熟能详的概念如：“低耦合”、“高内聚”，均来自GRASP原则。它与设计模式不同，设计模式指导如何实现系统，而GRASP旨在指导如何划分。

GRASP原则旨在指导定义业务架构以及API等相关内容和划分服务，其理论内容也非常多，只需要记住三个关键：

自己干自己的事； 自己只干自己能干的事； 自己只干自己的事，强调了资源划分。

在软件工程的教科书上给出了微服务架构的定义：微服务架构是一种架构模式，它是将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTFul API)。每个服务都围绕着具体业务进⾏构建，并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务⽽言，应根据业务上下⽂，选择合适的语言、工具对其进行构建。

而这些教科书上的内容或许在当下来看已经过时了。

微服务带来的优势

我们使用微服务架构的时候，到底得到了什么东西呢？这里总结了四点最为明显的优点：

使得开发和迭代变得更加敏捷，使用微服务架构使得敏捷开发成为可能； 易于扩展和收缩，一些公司基于Kubernetes、Docker等技术可以在几秒内拉起上万个微服务，当大型流量冲击到达的时候，可以实现无损地承担全部流量，同时实现用户无感知，而当数据访问量降低之后，又可以实现快速缩容； 多技术栈可能，目前云智慧的技术栈非常全面，虽然开发人员只有60多人，但是开发语言却多达10多门，而使用微服务可以有效地组织各类开发人员； 高可修改性，比如实现数据库的快速迁移，通道的快速切换等。

微服务带来的两点疑问

微服务能够带来诸多优点，但是也存在两点疑问：

第一个就是“微服务架构，你的系统变得更健壮了吗？”；

第二个则是“使用微服务让系统变得更快了吗？”

对于这两点而言，可能说是见仁见智的。有人说因为组件变得越来越多，可监控性就会变难，因此系统健壮性就会变得越来越差；也有人说因为将系统拆分得越来越细，因此健壮性就会越来越强。如果单体架构是串行的，那么使用微服务可以将其变成并行的和分布式的，而多个组件之间进行通信，也会使得通信成为性能瓶颈，那么使用微服务到底是变快了还是变慢了呢？这两个问题都很难以回答。作为一个架构师或者开发者需要不断进行深入的思考。

微服务架构面临的挑战和思考

这里总结了在使用微服务架构的时候所需要面临的8条挑战和相关的思考：

1. 小即是多

当业务从大变小的时候，也意味着业务变多了。由大变小，可以使系统变得更加容易维护和修改，但是由少变多，又会使得问题更加复杂，因此也会出现很多的挑战。

第一个问题就是多节点、多服务和多状态。系统中的节点、组件服务变得更多了，那么节点和服务之间的状态也会变得更难维护，更加复杂。基于前面提到的四种知识，可以将从大变小和从少变多这两个转变进行折中，使得其变得更加可控。而解决这个问题的关键在于对于服务的合理拆分，主要有三点可以考虑，即数据资源、业务功能以及服务对象。

2. 债务管理

Bug、代码缺陷、未完成的功能或者版本不兼容等问题都是债务。当服务变得越来越多的时候，债务往往就会变得更多。

为了解决这些问题，其实有这样的几种策略：

单元测试，如果单元测试做的足够好，那么代码缺陷的可能性就会变得更低一些，可以将服务由少变多所造成的债务变多情况进行收敛； 集成回归，这部分提供了很多工具去做这件事情，不用开发者自己去做； 版本管理，这里指的是静态库的版本管理，动态库指的是正在变更中的库，而静态库指的是不再变更的库和配置项，这一点控制不好，就容易使得系统管理混乱； 迭代冲刺，是一种组织方式，当有很多技术债务需要进行管理时，如何将这些债务一点点处理掉或者把发散的趋势收敛住，迭代冲刺就是一种做法； Bug Crash，这是智慧云团队自己发明的一个名词，相当于是对于Bug的大扫除，无论采用传统的还是敏捷的开发模式，都有一些Bug存在，因此定期会组织全体开发和测试以及产品将自己的产品用一遍，进行Bug大扫除； 回归总结，无论采用什么开发模式，在一个迭代周期完成之后，回归总结是少不了的，也需要通过一些方法解决新发生的问题，或者将其封闭住不使债务继续蔓延。

3. 复杂的服务依赖

如果只有一个或者几个组件，那么其实不存在服务依赖问题，而如果有几千个组件，那么服务依赖将会成为巨大的问题。举例而言，如果用户服务需要调用订单服务，那么在启动的时候需要进行一些初始化任务，那么一个服务的版本发布可能导致系统全面瘫痪，这就是复杂服务依赖问题。

为了解决这个问题首先就需要服务发现机制，比如使用etcd或者Zookeeper等，首先服务发现中心也需要是分布式高可靠的，那么服务起来之后需要把自己的名字和调用方式告诉服务发现中心，注册上去；对于服务调用者而言只需要从服务发现中心那里通过约定好的名字获取服务调用地址即可。

依赖唤醒是有一个相对比较新的东西，比如大流量突然打进来的时候，A服务需要从原来的10个启动到100个，而B从原来的3个肯定也是不够用的，因此需要通过唤醒的机制将服务拉起来，而不是被动的被通知。

还有一种情况也需要使用到依赖唤醒机制，比如缓存穿透问题，正常情况下，缓存是生效的，不会存在穿透的情况，但是可能因为某种异常使得缓存不生效了，会将大量的流量打到DB里面去，使得服务变得不可用了，整个服务雪崩掉，针对这些问题一般会开发一些挡板服务，可能会给出一些固定的数据，而这些挡板服务也有可能会面临这种突发的流量也需要通过依赖唤醒的机制实现唤醒。

此外，还有灰度发布和AB测试，这两点是相关联的。还有多版本共存问题，对于服务的多版本也是一个技术债务问题，需要考虑如何将其旧版本拿下来。

4. 消息通讯

如果系统中包含多个语言栈，多种实现方式。那统一标准是必须的，统一一种RPC或者就使用RestFul API等。消息中心也是一种处理做法，这一点在Java中应用很多，消息中心并不是消息队列，而是一个事件驱动的消息中心。此外，还有通讯网关，这在使用微服务的时候也是一个必要点，其主要解决了监控问题，而且可以通过网关起到中控的作用，比如安全、性能以及用户校验等任务。

5. 分布式事务

在实现分布式事务的时候可以采用2PC或者3PC原则来实现，2PC原则是通过全部节点投票和执行两个步骤完成的，并且是阻塞的；而3PC则不同，虽然在一个具体的事务里面可以是阻塞的，也可以是非阻塞的。3PC协议则是通过“Can-Pre-Do”三个步骤来实现的，其实PDU就是3PC协议在单体中的实现方式。而在分布式系统中，3PC有三种实现方式，使用分布式的事件驱动、最大通知以及两阶段补偿TCC。

6. 花式故障

很多时候，当系统出现问题可能需要花费数周和很多人力才能找到根源所在，可能因为系统太多，使得系统架构师也无法理清系统与系统之间的关系。面对诸多的花式故障，也有多种策略可以应对，比如全链路追踪，比如使用Open Tracking；主动拨测，很多用户端的APP里面内置探针，使其可以接收Server端的指令来定期探测接口和服务是否正常。

7. 中心与去中心

中心与去中心可以算是一个永恒的话题，上图中展示的配置、发号、日志、调度、状态以及预警，其实对于比较成熟的大型系统而言，这六点都是需要中心的。

8. 组织危机

最后一个问题，也是最大的问题。其实要实现向微服务架构的变更的时候，最大的问题就是组织危机。这一点与开发者关系不大，但是对于Team Leader以及组织的管理人员而言，关系非常大。架构的转变需要考虑到信任危机、过期维护、多语言栈、沟通协作、安全网关以及轮岗结对等问题。

总结

总结而言，最重要的观点有两个：微服务不是银弹，不要让重复的事情做两次。