我理解的微服务 -- 读《微服务设计模式》总结

微服务是针对公司某一复杂业务程序实现的设计模式, 与巨石架构(Monolith)是相对的.

微服务对应的应该是公司业务能力层级上的拆分与设计, 为了减少业务之间的耦合而导致相互拖累, 在对外业务能力不变的情况下, 在应用内部将能力拆分成一些微小服务. 也可以理解为是对巨石架构进行"解耦".

举个例子: 原先公司做的是一个外卖系统, 这个系统中可能包含了客户下单, 商家接单, 骑手配送等功能. 但是全部都打包在一个程序中. 发版时, 可能客户下单功能修改了功能, 导致商家没办法接单了. 或者商家接单功能实现的有问题, 导致整个应用程序挂掉, 现在用户下不了单, 骑手也没法接单, 整个公司的业务就瘫痪了. 然后, 在客户下单-商家接单-骑手配送这个大业务流程不变的情况下, 我们在外卖系统内部, 分成了多个服务, 各个服务之间使用 API 松耦合通信, 隔离影响. 比如, 客户下单服务, 专门处理客户下单这一业务, 并将生成的订单推送到消息代理 (如:kafka) 或直接推送给其他服务等, 它只要能保证完成它的职责即可. 后者, 就可以称之为 "微服务架构". 当然, 这只是一个例子, 实际情况会更加复杂.

在<<微服务设计模式>> 中对微服务的定义:

将应用程序构建为松耦合, 可独立部署的一组服务

书中也对"微"的大小给了定义:

大小的定义为能够由小团队开发服务

不用刻意地去追求服务的大小. 微服务的落地, 往往就会伴随着, 组织结构和开发的流程的改变, 由不同的 小团队 独立负某一服务.

像我们现在如果提到微服务, 就经常也会提到一些微服务框架 go-zero, go-micro 或者基础设施 docker, k8s 或者工具 gRPC, prometheus 之类的.

像这种框架和组件之类的只是一种技术工具. 他们并不能定义微服务, 他们可能只是为了克服微服务架构设计带来的某一些缺陷, 或者与微服务结合可以发挥出更大的价值.

举个极端的例子: 在你后端业务完全不划分的情况下, 你甚至可以在 go-zero 的框架基础上, 将你公司所有的业务打包进一个应用程序, 用 docker 打包, 并部署在 k8s 环境中, 再通过 gRPC 与前端通信. 你用到了很多著名的名词技术, 但是你实现出来应用的是巨石架构还是微服务架构呢?

参考

微服务设计模式