这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
什么是微服务架构
微服务架构是一种架构模式，它将单个大型应用程序拆分成许多小型服务，每个服务都可以单独部署和运行，以进行自主开发、测试和部署。每个服务都有自己的接口，可以与其他服务进行通信，也可以独立于其他服务运行。微服务架构的优势在于，它可以让每个服务的变化不影响整个应用程序，使得开发、测试和部署更加快捷、可靠。它还可以支持多种语言，支持不同技术栈，可以满足多种场景，从而带来更大的灵活性。
微服务架构的演变历史与逐步完善（重点）
!!! 下面内容很大程度上摘抄自 参考资料一 有兴趣的小伙伴可以戳开去看
以一个网上超市为例：
最初的需求
版本1:
随着业务扩展：ios端和安卓端还有 数据分析 促销管理功能
版本2:
这一阶段存在很多不合理的地方：
- 网站和移动端应用有很多相同业务逻辑的重复代码。
- 数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱。
- 单个应用为了给其他应用提供接口，渐渐地越改越大，包含了很多本来就不属于它的逻辑。应用边界模糊，功能归属混乱。
- 管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用。
- 数据库表结构被多个应用依赖，无法重构和优化。
- 所有应用都在一个数据库上操作，数据库出现性能瓶颈。 特别是数据分析跑起来的时候，数据库性能急剧下降。
- 开发、测试、部署、维护愈发困难。即使只改动一个小功能，也需要整个应用一起发布。 有时候发布会不小心带上了一些未经测试的代码，或者修改了一个功能后，另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响，所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行，还得盯到第二天白天的用户高峰期……
- 团队出现推诿扯皮现象。 关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久，最后要么干脆各做各的，或者随便放个地方但是都不维护。
是时候做出改变了
在编程的世界中，最重要的便是抽象能力。微服务改造的过程实际上也是个抽象的过程。小明和小红整理了网上超市的业务逻辑，抽象出公用的业务能力，做成几个公共服务：
- 用户服务
- 商品服务
- 促销服务
- 订单服务
- 数据分析服务 各个应用后台只需从这些服务获取所需的数据，从而删去了大量冗余的代码，就剩个轻薄的控制层和前端。
版本3:
这个阶段只是将服务分开了，数据库依然是共用的，所以一些烟囱式系统的缺点仍然存在：
- 数据库成为性能瓶颈，并且有单点故障的风险。
- 数据管理趋向混乱。即使一开始有良好的模块化设计，随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象。
- 数据库表结构可能被多个服务依赖，牵一发而动全身，很难调整。
如果一直保持共用数据库的模式，则整个架构会越来越僵化，失去了微服务架构的意义。因此小明和小红一鼓作气，把数据库也拆分了。所有持久化层相互隔离，由各个服务自己负责。另外，为了提高系统的实时性，加入了消息队列机制。架构如下：
版本5：
还有很多很多... 日志处理等等 详情可以去看大佬的文章
微服务架构的优点缺点
优点：
- 首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支 或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由 此，单个服务很容易开发、理解和维护。
- 第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某 些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在 技术重写以前代码也不是很困难的事情。
- 第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
- 最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。
不足的地方：
- 其中一个跟他的名字类似，『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一 些的，10-100 LOC服务组。尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。
- 另外一个主要的不足是，微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微 服务下这种技术显得更复杂一些。
- 另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
- 测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。
- 另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。 在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C， 然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。
- 部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用一般由大批服务构成。例如，根据Adrian Cockcroft，NetFlix 有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制（后续文章中发表），以用来发现与它通讯服务的地址（包括服务器地址和端口）。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用需要开 发者有足够的控制部署方法，并高度自动化。
优点：
- 明确边界
- 各种技术共存
- 每个服务有专门的团队来 开发 拓展
- 解耦各个服务 提高开发效率
缺点：
- 分布式本身的实现复杂度（通讯是采用rpc进行通讯）
- 数据库架构
- 测试一个服务可能要启动和他有关的所有服务
- 应用的改变会波及多个服务
- 部署下去的复杂度
参考资料
码风略丑 读者见谅 --2023/2/11
