微服务架构核心知识学习笔记上

1 什么是微服务

定义：微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 提出，微服务是一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能；每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（如HTTP）；每个服务围绕业务能力进行构建，并且能够通过自动化机制独立部署；服务会使用最小规模的集中管理 （例如 Docker）技术，每个服务可以使用不同的开发语言与存储技术。它有以下特点：
● 一组小的服务，微服务主张将大一体的服务拆成小的服务，架构师要取舍拆分粒度。
● 独立的进程。
● 轻量级通信，比如http。
● 基于业务能力，比如商品服务，用户服务，基于业务能力构建微服务。
● 独立部署，独立维护、独立迭代和部署。
● 无集中管理，分散治理，各个微服务可以独立选择合适自己栈。

2 微服务利弊

微服务也不是银弹，当你搞不定单块应用的时候，也别指望微服务能拯救你。
优势：
● 强模块化边界（以服务的方式作为边界）
● 可独立部署
● 技术多样性
劣势：
● 分布式复杂性
● 最终一致性
● 运维复杂性
● 测试复杂性

3 康威法则

康威法则：设计系统的架构受限制于产生这些设计的组织沟通结构。简单理解是就是系统架构（产品）必然要反应组织结构。
单块应用随着业务的发展，之前由一个团队变成了多个团队维护&开发，如果不对单块应用进行升级&拆分，这个就会违反康威法则，就会出现一些矛盾、协调成本比较高、交付效率低等问题。怎么解决这个问题呢？微服务就可以解决，对单块应用进行拆分。

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

先看下面一张图，横坐标是复杂度，纵坐标是生产力。从图中也可以看出，刚开始时候业务复杂度不高、系统功能也不多、商业模式没有得到验证，此时单块应用的生产力和效率比微服务高。随着业务逐步增长，业务的复杂度逐步提升，团队也原来越多，根据康威法则单块应用已经不在适合，此时可以考虑选择微服务架构，怎么权衡：这个需要架构师做出取舍，比如团队接近百人规模，就可以考虑采用微服务。

一开始的系统是直接选择微服务还是单块架构呢，尤其是新业务不推荐使用微服务，建议单块优先，主要原因以下：
● 一开始对问题领域不是很理解，很难把控怎么拆分服务以及划分边界
● 商业还没有被验证过，可能会失败，前期投入过高，而且生产力低不利与业务快速试错

5 什么样的组织架构更适合微服务

6 微服务中台战略

一线互联网标准的层次架构，可以分为四层：Iass->Pass->核心领域服务层（业务中台）>业务前台

7 服务分层

如下图所示，逻辑上大体可以分为两层。说明：BFF，即 Backend For Frontend（服务于前端的后端），也就是服务器设计 API 时会考虑前端的使用，并在服务端直接进行业务逻辑的处理，又称为用户体验适配器。

8 微服务技术架构体系

如下图所示微服务架的六大层次，可以认为是微服务基础技术架构的一个模板。

9 微服务技术架构体系

三种主流的服务发现模式，具体如下：
● 传统基于LB的模式，有一个独立的LB。优点：使用简单 缺点：集中的LB 变成了单点，性能消耗（需要穿透LB）。

• 进程内LB模式，LB维护在消费进程中，优点：没有集中式LB不存在单点问题，性能会比较好，缺点：需要为不同语言开发不同客户端，多语言支持成本会比较
  
• 主机独立LB模式，每一个客户端，主机上部署一个LB。优点：没有集中式LB不存在单点问题，性能会比较好，也能支持多语言。缺点：运维成本会比较高。

参考文献
[1] 极客时间-微服务架构核心20讲
[2] https://www.martinfowler.com/articles/microservices.html