微服务架构核心 20 讲 Study Notes

极客时间课程《微服务架构核心 20 讲》学习笔记

01 | 什么是微服务架构？

• 2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，他认为微服务是一种架构风格。Martin Fowler在其博客中讲到了什么是微服务，提出了6大微服务架构特点
  • 一组小的服务：把原先单体的服务拆分成一个一个微服务
  • 独立的进程：以进程的方式运行
  • 轻量级通信：http,rpc
  • 基于业务能力：基于业务能力构建微服务，例如用户服务，订单服务
  • 独立部署：每个微服务独立开发部署，开发团队间不需要更多协调（系统迭代速度，业务支持快）
  • 无集中式管理：每个微服务团队根据自身优势选择相关技术，无需统一
• Adrian Cockcroft（前Netflix公司架构总监）经历了Netflix公司从单体架构演化到微服务架构过程，他提出了微服务的三个特点：
  • 松散耦合，不能强依赖
  • 服务面向的架构（本质还是一种SOA）
  • 有界上下文（局部状态）：每个团队维护自己的数据源
• 思考：
  • 独立部署后给业务带来什么样的好处
  • 有界上下文（局部状态）带来了什么样的挑战？

02 | 架构师如何权衡微服务的利弊？

• 作为架构师需要了解微服务的优势和其带来的挑战，（架构最重要的一个职责就是权衡）

优势

• 强模块化边界
  • 最开始以jar包和类做模块化，后来以组件做模块化，微服务则更高一层，以服务的方式做模块化
  • 每个服务可以独立团队开发，有清晰边界
• 可独立部署
  • 独立开发，独立开发（一般不需要协同，减少协调成本）
• 技术多样性
  • 没有集中治理，可以选择团队自身擅长的技术栈（但不是技术越多越好，因为这也有成本）

挑战（劣势）

• 分布式复杂性
• 最终一致性
  • 不同服务（团队）的数据一致性
• 运维复杂性
• 测试复杂性
  • 需要不同团队一起做联合测试

思考

• 运维团队在面对分布式微服务的运维复杂性的时候，应该采用一些什么样的手段来应对？

03 | 康威法则和微服务给架构师怎样的启示？

• 康威法则：设计系统的架构受制于产生这些设计的组织的沟通结构

• 康威定律 (康威法则 , Conway’s Law) 是马尔文·康威1967年提出的。意即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式

• 康威定律源于模块的设计者需要互相之间频繁沟通。而跨部门交流比较难。

• 架构师不仅要做好技术架构，也要做好组织架构

04 | 企业应该在什么时候开始考虑引入微服务？

• 微服务有基础设施要求（前期投资）
• 推荐：一开始采用单体服务架构（成本小），经过业务复杂度提高可以慢慢演化成单体服务

• 思考：架构是设计出来的还是演化出来的？

05 | 什么样的组织架构更适合微服务？

• 微服务架构形成闭环

• 思考：怎么理解“微服务的架构本质是一种架构重组”？

06 | 如何理解阿里巴巴提出的微服务中台战略？

• 思考：大中台、小前台如何在公司中实践、落地

07 | 如何给出一个清晰简洁的服务分层方式？

• 逻辑划分

• 思考：自己的公司服务体系如何映射到基础服务、聚合服务

08 | 微服务总体技术架构体系是怎样设计的？

• 思考：为什么不建议初创型团队直接切入微服务，而是从单体应用开始？

09 | 微服务最经典的三种服务发现机制

• 在一个分布式的系统中，有很多生产者服务和消费者服务，这些消费者如何发现生产者，这就是微服务的服务发现问题
• 经过业界多年实践，总结出来三种主流的服务发现模式

传统基于LB的模式

• 目前大多数公司还是基于传统的LB做服务发现和负载均衡的
• 这种模式有一个独立的LB（Load Balancer，负载均衡器），比如使用硬件的F5负载均衡器，或者使用软件的Nginx负载均衡器
• 需要运维介入
• 优点：简单、成本低
• 缺点：
  • 需要集中的LB，这个LB可能是个单点，有单点故障风险
  • 消费者需要穿透LB去访问生产者，这个过程有性能开销

进程内LB模式

• 把LB的功能移动到了进程内，目前业界比较普遍的做法
• 服务提供方注册到一个注册表中，并定期发送心跳（告诉注册表自己还活着）
• 消费方应用进程内的LB（或者说带有LB功能的消费者应用服务）会定期同步服务注册表中的信息，并负载均衡调用服务提供方
• 优点：
  • 没有集中式LB，不存在单点问题
  • 比传统的LB性能好（不存在通过中间的集中LB再去访问服务提供方）
• 缺点：
  • 在多语言当中，需要在每个消费者内开发LB，升级成本，多语言支持的成本高

主机独立LB模式

• 在第一种和第二种的基础上做了一个折中
• 把LB以独立进程的方式独立部署在一台主机上
• 生产者把信息注册在注册中心，并维持心跳，消费者主机中的LB也会定期从注册中心同步信息
• 消费者调用生产者的时候其实是调用的它本机上的LB进程，LB负责负载均衡和远程调用
• 优点：
  • 没有第一种方式的单点问题和性能问题
  • 可以支持多语言，多种语言灵活接入，不需要为每种语言开发LB客户端
• 缺点：
  • 运维成本高：需要在每天机器上部署LB

• 思考：Service Mesh 最核心的点也是服务发现，那么它属于以上哪种服务发现机制？

10 | 微服务 API 服务网关（一）原理

• 思考：有些公司会把一些业务逻辑放在网关上，这样做的好处和弊端是什么？

11 | 微服务 API 服务网关（二）开源网关 Zuul

Reference

Remark

1. 复习的时候可以把每个图自己再画一遍，加深理解和印象
2. 了解学习Service Mesh

<font color=red></font>
![]()
<img src="" title="图片名称" alt="图片无法正常加载展示！" width="100%" height="100%" >
<center><img src="" width="70%"></center>
****