1.3.3　微服务的复杂性

微服务架构是一种复杂的设计，它包含多个组成部分。如果你有合适的负载均衡器，可以很容易地实现扩展；负载均衡器维护多个运行服务的列表，并为流量进行路由。底层服务可以纵向扩展，也可以收缩，这意味着服务可以按需创建和销毁。变化的跟踪是一个非常关键的问题。为了解决这一问题，我们引入了一个新的服务注册组件，如图1.4所示。

图1.4　微服务架构中的服务注册组件

每个微服务都需要一个运行的注册客户端，该注册客户端负责向服务注册表注册该服务。一旦完成注册，负载均衡器就开始向新的实例转发流量。服务注册表会对服务实例进行健康检测，若发现服务实例出现问题则执行解绑操作。这是微服务架构所面临的诸多技术挑战之一，也导致部署变得越来越复杂和困难。

了解了方案的优势及劣势，你还需要了解项目的实际情况，这对一个好的设计决策来说至关重要。如果你的项目对可扩展性没有很高的要求，同时团队规模也不大，采用单体系统可能是一个明智的决策。本书的每一章都会遵循相似的流程来评估设计决策：找到每种设计的优势及劣势，结合项目的上下文，解决困惑，即什么情况下哪种设计是更优的决策。

本章中，我们向你介绍了一个设计取舍的例子，在什么环境下如何做取舍是本书试图回答的核心问题。通过本章，你应该了解了如何为你的应用选择恰当的单元测试与集成测试比例，及其底层的利弊取舍。我们也讨论了像单例模式这样久经考验的解决方案不一定是最合适的选择，我们需要结合实际的使用场景进行判断。譬如，如果你的系统采用多线程的环境，采用单例模式时可能会由于线程竞争导致一定的性能问题。最后通过高层设计选择的例子，我们对微服务架构与单体系统设计模式进行了对比。

第2章中，我们会讨论代码重复与复用之间的取舍。我们认为代码重复不一定都是反模式的或者是坏事，同样，做判断时我们需要充分结合上下文。