我看微服务架构

本文的内容主要来自于极客时间《从 0 开始学架构》、《后端技术面试 38 讲》、《从 0 开始学微服务》专栏中有关微服务的部分

首先，我觉的不是所有的企业都需要微服务；其次，也不能总想着跨越式发展，弯路可以少走一些，但是该做的事情，比如领域建模、业务分析、架构设计……，一件也不能少。

有点好奇，除了互联网大厂，还有哪些公司在做微服务，有没有成功案例？

看过王健老师的中台专栏，也认可他总结的“中台是企业级能力复用平台”，但是对于“中台”这个国产概念，持谨慎怀疑态度，其实和之前在系统中抽象出来的服务层有点类似。

EJB、SOA、微服务、中台……感觉上似乎都是概念先行。

大厂的人、财、物各种资源充足，搞一下“微服务”或者“中台”当然不在话下，但是中小公司也可以么？或者说有必要么？

“倒三角模型”应该是技术领域通用的，无论是微服务还是中台，或者是其他什么技术，都应该从需求、价值、原则、实践、工具的线索去梳理。

微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。服务会使用最小规模的集中管理（例如 Docker ）技术，服务可以使用不同的编程语言与数据库等。

服务化将传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。通过服务化，可以解决单体应用膨胀、团队开发耦合度高、写作效率低下的问题。

微服务相比服务化，拆分粒度更细，可以独立部署和维护，相应的服务治理能力要求更高。

我有点怀疑国内一些公司号称上了微服务，其实还有很多微服务所需要的基础设施并没有健全，甚至连业务建模、系统抽象之类的事情都没有做好。

如果对比在架构设计中常见的子系统、子模块，感觉微服务无非是拆分粒度更小、抽象层次更高、通讯协议更简洁。以前架构设计或者说软件设计的理想也是能够将小的组件或者模块尽可能的复用，这个和采微服务的目标也有些近似。

微服务肯定不是银弹，如果使用得当，应该也不会是焦油坑，可能更多的是一种设计理念，而不是框架。

3 个人负责开发一个微服务，每个微服务由 2 个人负责维护，的确是一个很好的人力资源配置标准。

微服务可以按照业务逻辑（其实是按照团队规模？）以及可扩展、高可用、高性能（架构设计三原则？）来拆分。

微服务所需要的基础设施确实比较多，但是搭建了微服务基础设施之后，应该是可以重复利用的——一次搭建，多处使用。

其实在微服务的 11 个基础设施里面，我觉得自动化测试和自动化部署反而是比较基础的，并且需要开发人员能够适应并且投入。不知道国内有多少团队能够做到单元测试，或者是自动化测试；自动化部署因为有 Jenkins，可能会好一点。

如果按照上一章节的优先级顺序，应该从服务发现、服务路由和服务容错起步，然后再做接口框架和 API 网关；最后是服务监控、服务跟踪和服务安全。

很多系统都经历过“单体应用-微服务架构-容器化应用-DevOps”的发展历程，不知道现在的互联网大厂是否都已经到了 DevOps 的阶段？感觉上一般的软件企业（非互联网）可能还是在单体阶段吧，当然也可能是因为体量不大，所以不需要服务化？

微服务架构的思路有点类似于软件设计中的“高内聚、低耦合”，抽象层次更高一些。

可能要去做 ToG 的项目经理，有点好奇，定制化开发的项目能否用到微服务？感觉上如果能用微服务架构的话，可能可以提高模块的复用程度。

即使是定制开发，其中也必然会有类似的功能，可以把不同项目中相同的模块拆分出来，采用 Docker 进行部署，可能可以行得通。

先写这么多，有机会的话再继续。