这是我参与「第五届青训营 」伴学笔记创作活动的第 4 天
在了解微服务架构之前，我们首先来了解一下与之相对的单体架构。
单体架构： 把系统所有的功能模块耦合在一个应用的架构方式
优点：
部署简单 技术单一 用人成本相对低 项目管理相对较易 测试相对简单直观 应用开发相对简单 横向扩展容易
缺点：
- 项目过于臃肿，bug难以迅速定位
- 资源无法隔离(某个功能模块对应的接口访问量大，直接会影响整体性能)
- 无法灵活扩展 ：单体架构只能以一个整体来进行扩展，无法结合业务模块的特点进行伸缩。
- 交付周期长 单体应用程序的开发需要大量时间来构建，因为每个特性都必须一个接一个地构建
- 部署消耗时间长 ：随着代码的增加，构建和部署的时间也会相应的增加。
- 可靠性差 系统的一个功能不起作用，那么整个系统也不起作用
- 受技术栈限制 同一个单体架构下的员工必须用同一种语言
- 复杂度高 ：整个项目包含的模块过多，边界模糊
微服务架构
在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，服务之间相互协调，相互配合
功能：
- 解耦——系统内的服务在很大程度上是解耦的。因此，整个应用程序可以轻松构建、更改和扩展。
- 组件化——微服务被视为可以轻松更换和升级的独立组件。
- 业务能力——微服务非常简单，专注于单一能力。
- 自治——开发人员和团队可以彼此独立工作，从而提高速度。
- 持续交付——通过软件创建、测试和批准的系统自动化，允许频繁发布软件。
- 责任——微服务不关注应用程序作为项目。相反，他们将应用程序视为他们负责的产品
- 去中心化治理——重点是为正确的工作使用正确的工具。这意味着没有标准化的模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的问题
- 敏捷性——微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃
优势：
- 独立开发，所有微服务都根据各自的功能轻松开发
- 独立部署，可以单独部署在任何应用程序中
- 故障隔离，应用程序一项服务不工作，系统仍然继续运行
- 混合技术栈，不同的语言和技术可用于构建同一应用的不同服务
- 可以灵活拓展，单个组件可以按需进行拓展，而不需要所有组件一同拓展
缺点：
- 维护成本高， 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug
- 新人培养周期长，需要较长时间来理解背景
- 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展
- 多功能增加了运维服务
- 服务之间的通信成本
