学习笔记：微服务设计的IDEALS原则

一、'IDEALS原则'概述

• 接口分离（Interface segregation）
• 可部署性（Deployability (is on you)）
• 事件驱动（Event-driven）
• 可用性 胜于 一致性（Availability over consistency）
• 松耦合（Loose coupling）
• 单一职责（Single responsibility）

二、细说'IDEALS原则'

1、接口隔离（物以类聚）

• 微服务接口隔离的目标：是确保每种类型的前端都能对接最匹配其需求的服务契约。
  根据不同客户端、不同的应用场景要求的数据特点，提供不同的服务。例如，Native提供短JSON数据；Web提供完整JSON；IM数据需要系统XML数据格式等等。

• 解决方案：API 网关 和 BBF模式
  最流行的解决方案就是使用 API 网关，可以实现消息格式转换、消息结构转换、协议桥接、消息路由等功能。
  另一种流行的替代方案，即面向前端的后端（BFF）模式，示意图如下。

  
  image.png

2、可部署性

• 微服务需要时刻关注，软件是否能被正确打包并部署特定环境中。

• 关注于自动化部署：
  要实现自动化，我们需要正确选择工具与技术，这也正是自微服务架构出来以来变化最大的领域所在。

3、事件驱动（异步不等待）

微服务带来的问题就是服务器小而多，众多微服务器间的如何进行通信？同步还是异步？这些关键设计直接影响了微服务的高效和成功。
其中，事件驱动架构的一大核心优势，在于显著提高了系统的可扩展性与吞吐量。而这一优势之所以能够实现，是因为消息发送方不会因阻塞而等待响应，而且多个接收方可以通过发布 - 订阅的方式并行使用同一消息 / 事件。

4、可用性 胜于 一致性（能不能用才是关键）

• CAP 定理：本质上提供了两种选择：要可用性 或者 要一致性。
  CAP 定理指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

  用户的实际体验和诉求中，可用性 高于 一致性。
  正如 Pat Helland 所指出，在马上得到答案和得到正确答案之间，大多数人想要的其实是马上得到答案。

• 在微服务当中，实现可用性的主要策略在于数据复制。

5、松耦合（减少交互，保持简单）

在软件工程中，耦合是指两个软件元素之间的相互依赖程度。对基于服务的系统而言，传入耦合主要涉及服务用户如何与服务进行交互。

6、单一职责（单一才能专心，专心才能高效）

• 扩展到微服务架构内的服务内聚性层面。
  最初的单一职责原则（SRP）旨在强调 OO 类应具有内聚功能。
  为了保持单一性，微服务架构规定各个部署单元应该只包含一项服务或者几项内聚服务。

参考

微服务设计的原则：IDEALS，而不是SOLID