《从零开始学微服务》课程学习笔记（二）

从单体应用走向服务化

什么时候进行服务化拆分

• 微服务就是将庞杂臃肿的单体应用拆分成细粒度的服务，独立部署，并交给各个中小团队来负责开发、测试、上线和运维整个生命周期。
• 项目第一阶段的主要目标是快速开发和验证想法，证明产品思路是否可行。
  • 这个阶段功能设计一般不会太复杂，开发采取快速迭代的方式，架构也不适合过度设计。
  • 所以将所有功能打包部署在一起，集中地进行开发、测试和运维，对于项目起步阶段，是最高效也是最节省成本的方式。
  • 当可行性验证通过，功能进一步迭代，就可以加入越来越多的新特性。
• 一旦单体应用同时进行开发的人员超过 10 人，这个时候就该考虑进行服务化拆分了。
  • 纵向拆分
    • 将不同的功能模块服务化，独立部署和运维。
    • 从业务维度进行拆分。
    • 标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
  • 横向拆分
    • 从公共且独立功能维度拆分。
    • 标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

服务化拆分的前置条件

• 服务如何定义
  • 对于单体应用来说，不同功能模块之前相互交互时，通常是以类库的方式来提供各个模块的功能。
  • 对于微服务来说，每个服务都运行在各自的进程之中，应该以何种形式向外界传达自己的信息呢？
  • 无论采用哪种通讯协议，是 HTTP 还是 RPC，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。
• 服务如何发布和订阅
  • 单体应用由于部署在同一个 WAR 包里，接口之间的调用属于进程内的调用。
  • 拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调用者该如何查询所需要调用的服务的地址呢？
  • 这个时候就需要一个类似登记处的地方，能够记录每个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。
• 服务如何监控
  • 通常对于一个服务，我们最关心的是 QPS（调用量）、AvgTime（平均耗时）以及 P999（99.9% 的请求性能在多少毫秒以内）这些指标。
  • 这时候就需要一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功能。
• 服务如何治理
  • 拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。
  • 比如一个服务的性能有问题时，依赖的服务都势必会受到影响。
  • 可以设定一个调用性能阈值，如果一段时间内一直超过这个值，那么依赖服务的调用可以直接返回，这就是熔断，也是服务治理最常用的手段之一。
• 故障如何定位
  • 在单体应用拆分为微服务之后，一次用户调用可能依赖多个服务。
  • 每个服务又部署在不同的节点上，如果用户调用出现问题，需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。
• 无论是纵向拆分还是横向拆分，都是将单体应用庞杂的功能进行拆分，抽离成单独的服务部署。
  • 但并不是说功能拆分的越细越好，过度的拆分反而会让服务数量膨胀变得难以管理，因此找到符合业务现状和团队人员技术水平的拆分粒度才是可取的。
  • 建议的标准是按照每个开发人员负责不超过 3 个大的服务为标准，毕竟每个人的精力是有限的，所以在拆分微服务时，可以按照开发人员的总人数来决定。