单体架构到分布式应用
单体架构与分布式应用特性对比
微服务的优势与缺陷
人月神话一书中提及，没有银弹，意思是只靠一把锤子是盖不起摩天大楼的，要根据业务场景选择设计思路和实现工具。当我们在构建现实中的微服务系统中，其面临的问题又可以细化为服务拆分与服务治理等不同的考虑维度，微服务并不等同于我们选择了 Dubbo 或者 Spring Cloud 等某种微服务解决方案，而是源自内部的业务划分、组织架构。
当我们以这种方式考虑微服务时，我们可能会质疑为什么我们会完全采用微服务架构。答案通常是独立部署和扩展。对于大型的整体应用程序，组织不得不一次部署或释放所有代码。应用程序的每个新版本都可能涉及许多更改。部署变得既危险又费时。任何人都可以使整个系统瘫痪。换句话说，组织为了获得运营利益而采用微服务，而以性能为代价。组织还必须承担维护支持微服务所需的基础架构的成本。事实证明，在许多情况下，这种折衷是有道理的，但它也强烈反对过早采用微服务架构。
微服务的优势可以如下所述：
- 每个服务足够内聚，足够小，代码容易理解、开发效率提高；
- 服务之间可以独立部署，微服务架构让持续部署成为可能；
- 每个服务可以各自进行 x 扩展和 z 扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；
- 容易扩大开发团队，可以针对每个服务（Service）组建开发团队；
- 提高容错性（Fault Isolation），一个服务的内存泄露并不会让整个系统瘫痪；
- 系统不会被长期限制在某个技术栈上； 系统的可靠性。在微服务架构中，整体系统的可靠性上升。单个服务可以在不影响整个系统的情况下宕机（并被回滚）。 关注点的分离。从架构上来看，微服务架构迫使你去问 “这个服务为什么存在？“更加清晰地定义不同组件的角色。 明确所有权。代码拥有者变得更加清楚。服务通常由个人、团队或组织级别拥有，从而实现更快的增长。 自主执行。独立的部署 更清晰的所属权限，让不同的产品和平台团队能够自主执行。 开发人员的速度。应用团队可以独立部署他们的代码，这使得他们能够按照自己的项目进度来执行。
但是，随着公司规模的扩大（从 100 名工程师增加到 1000 名工程师），我们开始注意到与系统复杂性大大增加相关的一系列问题。使用微服务架构，人们可以将单个整体的代码库换成黑匣子，黑匣子的功能可以随时更改，并且很容易引起意外行为。
其典型的缺点可以如下所示：
- 开发与运维复杂度的增加：开发人员要设计服务之间的通信机制，对于需要多个后端服务的业务场景，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性；
- 真实系统往往难以明确划分边界：在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹；
- 状态管理与通信的复杂度；
- 分布式事务与版本管理；
由于服务之间的调用可能会深入很多层，因此了解服务之间的依赖性可能会变得非常困难。第 n 个依赖项中的延迟峰值可能会导致上游问题的级联。如果没有合适的工具，就不可能看到实际发生的事情，从而使调试变得困难。为了构建简单的功能，工程师经常必须跨多个服务工作，所有这些服务都由不同的个人和团队拥有。这就需要大量的协作以及花在会议，设计和代码审查上的时间。当团队在彼此的服务中构建代码，修改彼此的数据模型甚至代表服务所有者执行部署时，先前明确的服务所有权承诺将受到损害。可以形成联网的整体，其中必须将似乎独立的所有服务一起部署以安全地执行任何更改。