摆脱单体架构黑洞>>>>走向微服务的乐园

 

章节内容：

• 描述什么是单体架构黑洞和如何使用微服务来解决它
• 以架构风格定义微服务架构
• 解释微服务架构的有点和缺点
• 描述微服务模式语言和为什么要使用它
• 讨论为什么现代的大型、复杂的应用开发必备的三件事情：微服务架构、开发运维、小型自治团队

（注：FTGO代指外卖应用，这里不方面使用真实名字）

FTGO是一个典型的采用了分层、多模块的企业级应用。应用的核心是商业规则逻辑组件，外网是各种各样的适配器，例如UI界面和集成外部系统。如下图

商业规则由包含服务和领域对象组成的模块构成。例如：订单管理、配送、账单和支付等。有几个适配器作为接口与外部系统交互，包括数据库访问组件、消息队列组件、Web应用和Rest Apis。

尽管FTGO拥有一个逻辑上的模块化架构，但应用本身却作为单个程序集并部署在服务器上。

单体架构的优点应用非常容易开发。开发工具和插件都是以单个应用为基础模板。从新建项目到测试的连接也非常流畅，易于调试。部署只需要拷贝单个程序集即可。扩展也简单，只需要使用负载均衡组件即可。

单体应用的黑洞

作为一个有经验的开发人员，会深刻体会到，单体应用有一个巨大的限制。随着商业的增长，会伴随着一个习惯。每次冲刺新增需求，即时是小的用户故事，也会让代码急剧膨胀。随着商业的更加成功，

开发团队的规模稳步增长。这样不仅增加了代码基的增长率，而且增加了管理开销。

曾经的简单、小规模的应用经过多年的维护之后变成了一个被众多开发人员支撑的大泥球。随之而来的就是开发速度减慢，开发过程痛苦。敏捷开发和部署变得不可能了。

压倒性的复杂度限制了开发人员

一个主要的问题就是应用太TM复杂以致于没有人可以理解全局并掌控。修改bug和增加新特性变得困难和耗时间，估算的上线时间经常被延后。

作为单个进程来运行，任何一个bug或模块有时会引起整个应用崩溃。

作为一个程序集来开发，只能使用单个技术栈，不能利用多语言多平台的优势。

微服务来救场

功能性需求是架构设计中的一个重要方面，但却与之关联很小。架构之所以重要，是因为它如何影响所谓的非功能需求。

一方面，优秀的开发人员可以可以延缓单体架构黑洞造成的影响，但是要从根本上解决，只能使用--微服务。

我理解的微服务

我对微服务的定义，灵感来自于 《The art of scalability》。这本书描述了一个很有用的、三维扩展模型：规模的立方体。

X轴：一个通常采用的扩展应用的方法。你只需要采用负载均衡并部署多个实例。

Z轴：也是运行多个应用实例，不同在于每个实例只处理部分请求

Y轴：X和Y提高了应用的处理能力和可用性，但是要从根本上解决问题，还得使用Y轴——将应用分解为服务

 

综上，直观上面来理解，微服务是这样一种架构风格——把应用分解为多个服务。是不是so easy！！！

和SOA的异同

从顶级视角来看，和SOA非常相似，都是以多个服务来架构系统的。但是深入进去，你会发现，还是有很大差异的。

SOA应用一般使用重量级的技术，例如SOAP和其他WS*标准，具体的如WCF/web service等。它们通常使用ESB（包含了业务和处理逻辑）来集成系统。

而MICROService倾向于采用轻量级的开源的技术。服务直接的通信采用消息转发或者轻量级的协议如REST 或 gRPC。

在对待数据方面，也是有差异的。

SOA通常会有一个全局的数据模型和共享数据库，而microservice每个服务都要自己的数据库和自己的领域模型。总的来说就是，microservice非常强调服务的自治和独立性。

microservice architecture的优缺点

优点：

• 每个服务都是很小、可维护的应用
• 服务是可以独立部署的
• 服务是可以独立扩展的
• 使得团队变成了自治的
• 使应用新技术变的更容易
• 极大改进了错误隔离

缺点：

• 分布式系统本身的复杂性
• 查找可用服务是一个挑战
• 部署跨多个服务的特性需要仔细的协调
• 决定何时采用微服务是很困难的

对于面向最终用户的Web应用和Saas平台应用，使用microservice是非常合适的。而使用microservice需要解决设计和体系结构的问题，但是每个问题又有多个解决方案。这就要求你必须熟知每种问题和解决方案，并做出合适的决定。

架构模式（套路）

架构和设计，本质上来讲，就是关于软件进行的决策。模式（套路）就是在特定上下文中经常发生的问题的可重用的解决方案。首先考虑问题的上下文是很重要的，没有最好的解决方案，只有最合适的解决方案。

套路总览——————————————

• - 前置和结果关系.
  
• -解决一个问题的关系
  
• - 一般和特殊的关系.

Decomposition patterns

Communication patterns

不仅要考虑服务之间的交互方式，还要考虑客户端与服务的交互方式。一个选项是客户端直接与每个独立的服务通信。另一个选项是所有的客户端通过API Gateway来路由请求、合并多个服务的响应。

Data consistency patterns

Querying patterns

Deployment patterns

Observability patterns

 

Testing patterns

 

 

微服务的人员组织和开发过程

 

 最好配套敏捷开发的方式。