微服务底层逻辑&笔记

---

0.前言

  相关内容主要是阅读《微服务架构设计》的一些所得及吐槽，内容作为笔记、周记的属性更重，若有幸被人看到，欢迎吐槽、指正。

---

1.单体应用

  单体应用最直观的感受就是一个服务做完所有的事情，java里就是一个可执行jar包。小公司、创业公司适合采用这中架构，创建一个工程就开始干，什么功能往里边怼，一个字：又简单又快，祥述就是¹：

1. 开发简单
2. 便于大规模更改
3. 测试直观、部署简单
4. 横向扩展简单，只需要一个负责局衡器

  但是随着功能不断增多，整个服务容易变成一个单体地狱，代码也完全变成一个泥球：

1. 应用过于复杂，新人上手困难，问题排查困难
2. 开发进度缓慢，每次构建、部署、测试需要更多时间
3. 发版困难，容易出问题，按期交付困难²
4. 难以扩展，不同的功能对机器的要求侧重不同，单体应用的机器需要满足所有的要求
5. 技术栈更新困难，历史包袱过重

  基于这些背景，当业务发展到一定体量，验证了业务可行性后，服务的拆分好像就成了一件理所当然的事情。

2.微服务

2.1 微服务三个维度

  服务的扩展有三个维度³：

• x轴：就是最常见的多实例部署，为了抗量，一个服务部署个200台机器很正常
  • 多实例部署，就需要做负载均衡，做服务注册、发现
• y轴：服务的功能拆分，如一个商城服务，拆成订单服务、购物车服务、商详服务、推荐服务、投放服务等等
  • 方法调用从服务内调用变成了rpc调用，一个数据库变成多个数据，因此需要rpc调用框架、分布式事务管理
  • 接口整体的可用性收到每个服务接口的影响，于是有了接口限流、熔断，有了服务的降低、兜底
  • 跨多服务查问题困难，于是有了trace，记录请求的全链路
• z轴： 数据分区，就是常说的分库、分表

  微服务的出现解了单体服务的很多问题，但“没有一项技术可称为银弹”，微服务带来问题也很多⁴：

• 服务的拆分和定义是一项挑战
• 分布式系统带来跟中复杂性，使开发、测试和部署变困难⁵
• 跨服务的功能需要多个团队协调
• 开发者需要西靠什么阶段使用微服务架构

2.2 微服务是一种架构风格

2.2.1 mvc分层

  web应用中比较流行的是mvc三层架构：表现层、业务逻辑层、数据持久化层。优势是概念清晰，但这段时间感受比较深的是其导致依赖问题：

service定义数据访问方法的接口或接口库，DAO层实现service层的接口，这就使得service层必须依赖DAO层，这种依赖关系跟分层架构所描述的是相反的。

2.2.2 六边形风格

比较直观的介绍可参考：六边形架构入门与实践

  关于六边形架构，从代码实践角度来讲，个人觉得是在domain层定义好各个领域的业务逻辑、与外部领域交互的接口定义好，其它模块负责具体实现，所有其它模块直接、间接的依赖domain模块，这样以业务层为中心的代码组织方式就不会有mvc结构的问题。

  服务的api封装了内部实现，与单体架构不同，开发人员无法绕过服务的api直接访问服务内的方法或者数据。因此，微服务架构强制实现了应用程序的模块化。

2.3 定义微服务架构

  架构的定义没有机械化的流程可遵循，介绍一种大概的方法：

• 定义操作系统
  • 操作系统是应用程序必须处理的请求的一种抽象描述，既可以是写操作，也可以是读操作
  • 操作系统是描述服务之间写作方式的架构场景
• 定义服务
  • 由于服务的网络往返太多，特定的分解是不合实际的
  • 过多的api调用降低可用性
  • 分布式事务
  • 消除上帝Class
• 定义服务api和协作方式

2.3.1 识别操作系统

1. 创建由管件类组成的抽象领域模型，这些关键类提供用于描述操作系统的词汇表

创建领域模型会采用一些标准的技术，例如通过与领域专家沟通后，分析用户故事和场景中频繁出现的词

2. 确定系统操作，并根据领域模型描述每个系统操作的行为

  识别系统指令的切入点是分析用户故事和场景中的动词；操作系统分为两类：

• 命令型：创建、更新或删除数据的系统操作
• 查询型：查询和读取数据的系统操作

可参考 CQRS架构

2.3.2 拆分服务

根据业务能力拆分
  个人理解是根据业务功能拆分，例如商城服务需要有的功能有：搜索功能、商品列表查看功能、商详功能、购物车功能、下单功能、商品信息管理功能等，这些功能跟技术实现无关，就是一个业务的功能划；一个功能还能分为多个子功能。

业务功能的拆分是客观的，但是并不是每一个功能就一定就是一个独立的服务，特别是针对众多的子功能会进行合并，决定将那个级别的能力映射到一个服务是非常主观的

根据资源拆分服务
就是DDD

拆分的指导原则

1. 单一职责原则
2. 闭包原则：当需求发生变化时，影响尽可能少的服务

总结

  主要记录了从单体应用转换到微服务的原因以及定义微服务时的一些问题及方法。

---

1. 书中pageNo 4 ↩︎

2. 公司前端发版困难，先回归单个功能，在集成测试，还经常回滚，应该就是这个原因吧 ↩︎

3. 书中pageNo 9 ↩︎

4. 书中pageNo 17 ↩︎

5. 个人觉得，应该是整体的复杂度变高了，局部单个服务是变简单了 ↩︎