1.5 微服务架构的挑战

将一个系统分散到多个微服务中使得系统整体结构变得更加复杂，这在技术和架构上同样给我们带来了一定挑战。同时，由于各个微服务都需要独立部署，我们就会有更多的服务需要单独进行发布和运行管理，运维基础设施也会面临比单块系统更大的困难。最后，微服务架构在很大程度上改变了系统的研发过程，从团队协作到需求管理等方面，都需要通过引入变化进行调整和完善。

1.5.1 技术架构挑战

微服务架构是一种分布式架构，各个微服务之间需要通过网络通信完成交互。网络在连通各个微服务的同时也会产生响应时间的延迟和通信过程的不可靠性。关于分布式系统固有的问题我们已经在1.1.2节中做了介绍，这里不再赘述。另外，我们还需要注意到微服务架构中的去中心化思想和服务版本控制所带来的系统复杂性。

1.去中心化与平衡

微服务架构所带来的独立性可能导致每个服务采用不同的技术体系。去中心化的设计思想意味着微服务之间不需要共享技术，然而缺少通用的技术体系同样也会加剧系统的复杂度。去中心化是微服务架构的基本特征之一，但当每个微服务团队都采用自身团队擅长的不同技术进行微服务构建时，导致的问题就是没有一个人能够明白系统中所采用的所有技术。尽管多数情况下，我们并不需要深入到其他团队的微服务中，但当从统一发布和运维等角度去看待整个系统时，这种技术复杂性就可能会是一个问题。我们需要把控中心化和去中心化之间的平衡性。

2.服务版本控制

每个微服务都应该具备与其他服务保持相互独立的版本控制机制，我们提倡为每个微服务建立版本并根据业务迭代更新这个版本。如果每个服务都能够完全按照自身服务的演进过程进行独立发布，那么事情还比较简单。但如果某一个服务与另一个服务具有版本关联性，即这两个服务要么都不发布、要么一起发布，那么事情就变得有点复杂。如果这些具有版本关联性的服务很多且版本的更新频率很高，如何正确地管理服务版本就是一项具有挑战性的工作。

1.5.2 研发过程挑战

在技术之外，采用微服务架构也可能带来研发过程上的挑战。

1.需求的边界

对研发过程而言，分散的服务在一定程度上等同于分散的业务需求，来源于微服务具有的业务独立性和明确的服务边界。但对于整个系统而言，需求的边界并不会那么容易划分。当我们面对微服务架构，如何确定业务功能的粒度、如何把非功能性需求分解到各个微服务中、如何从系统整体上把握需求的优先级等都是我们不得不面对的问题。

2.引入变化

对于大多数尚未采用微服务架构的团队而言，使用微服务架构就是一个引入变化的过程。关于团队引入变化，很多人存在一些误解，其中最大的误解就是认为新想法一旦引入就意味着已经成功。当我们尝试采用微服务架构时，团队管理人员想了很多办法、做了很多工作，找到了问题的切入点，跟各个利益方讨论之后终于引入了大家都赞同的变化，然后就期望这个变化能按照自己想的那样发挥效果，这是不对的。当微服务架构被引入时，我们还要做很多事情，因为前面所提到的各种技术、架构和过程的挑战都需要我们进行跟踪和协调。