学习笔记：《微服务架构设计模式》之逃离单体地狱

目录

1.1 什么是微服务

1.2 微服务架构作为模块化的一种形式

1.3 每个服务都拥有自己的数据库

1.4 微服务架构的好处

1.5 微服务架构的弊端

1.6 模式和模式语言

        1.6.1 微服务架构的模式语言概述

---

1.1 什么是微服务

        把应用程序功能性分解为一组服务的架构性风格。

1.2 微服务架构作为模块化的一种形式

    微服务架构使用服务作为模块化的单元。服务的API为它自身构筑了一个不可逾越的边界,你无法越过API去访问服务内部的类，这与采用Java包的单体应用完全不同。因此模块化的服务更容易随着时间推移而不断演化。微服务架构也带来其他的好处，例如服务可以独立进行部署和扩展。

1.3 每个服务都拥有自己的数据库

    实现每个服务之间松耦合，每个服务都拥有自己的私有数据库。Order Service拥有一个包括Orders表的数据库，Customer Service拥有一个包含Customers表的数据库。在运行时，服务实现相互之间的独立，服务不会因为其他服务锁住了数据库而进入堵塞的状态。

1.4 微服务架构的好处

• 使大型的复杂应用程序可以持续交付和持续部署。

• 每个服务都相对较小并容易维护

        相比之下每个服务都比较小，开发者更容易理解服务中的代码，能够快速地启动服务，提高开发速度。        

• 服务可以独立部署
• 服务可以独立扩展

        服务可以独立扩展，不论是采用X轴扩展的实例克隆，还是Z轴扩展的流量分区方式。此外，每个服务都可以部署在适合它们需求的硬件之上。这跟使用单体架构的部署和硬件选择是迥然不同的:单体应用中组件对硬件的需求不同(例如有些组件是CPU运算密集型的,有些可能需要更多的内存空间)，但是这些组件仍旧必须被部署在一起。

• 微服务架构可以实现团队自治
• 更容易实验和采纳新的技术

        因为服务都比较小，使用更好的编程语言和技术来重写一项服务变得有可能。

• 更好的容错性

        微服务架构也可以实现更好的故障隔离。例如，某个服务中的内存泄漏不会影响其他服务。其他服务仍旧可以正常地响应请求。相比之下，单体架构中的一一个故障组件往往会拖垮整个系统。

1.5 微服务架构的弊端

• 服务的拆分和定义是一项挑战。

        没有一个具体的、定义良好的算法可以完成服务的拆分工作。对系统的服务拆分出现了偏差，你很有可能会构建出一个分布式的单体应用: 一个包含了一大堆互相之间紧耦合的服务，却又必须部署在一起的所谓分布式系统。这将会把单体架构和微服务架构两者的弊端集于一身。

• 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难。

        开发人员必须创建分布式系统的额外复杂性，服务必须使用进程间通信机制，比简单的调用方法复杂。每个服务都有自己的数据库，这使得实现跨服务的事务和查询变得复杂。

• 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队。

• 开发者需要思考到底应该在应用的什么阶段使用微服务架构。

1.6 模式和模式语言

        模式：针对特定上下文发生的问题的可重用解决方案。

        模式语言：解决特定领域内问题的相关模式的集合。

        1.6.1 微服务架构的模式语言概述

        微服务架构的模式语言是一组模式，可帮助架构师使用微服务架构构建应用程序。图1-10显示了模式语言的结构。模式语言首先帮助架构师决定是否使用微服务架构。它描述了单体架构和微服务架构，以及它们的好处和弊端。然后，如果微服务架构非常适合当前的应用程序，那么模式语言可以帮助架构师通过解决各种架构和设计问题来有效地使用它。