我看微服务(Microservices)

微服务（Microservices）是什么，众说纷纭，不过要说到名词解释，必须看 Martin 的 Microservices 介绍 :

…… the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

听起来好像就是松散的互联网结构，我认为微服务（Microservices）有 4 个鲜明特点：

• 设计解耦（design independently）/商业拆分：这里讲的架构不是技术架构，而是商业逻辑架构（脱离用户需求的架构都是耍流氓），这在大层面上决定了软件如何拆分，系统方面 cross-cutting 的东西可以拆分出来。拆分的好处是整个架构可以各部分可以各自演变，这可以应对商业需求在情况下不明确或者比较复杂下，先找出”基本解”。design independently 接下来的好处就是各部分架构是 持续可演化性 （continuously evolutionary），引入创业公司 MVP（most valuable product）的做法，边做边找最佳方法，而单体架构（monolithic），在商业不明确或比较复杂情况下，设计时间不确定，导致开发迟迟无法开动；同时一个部分的变化会直接引发整体做出变化，这导致两种恶性后果，一是某一部分成为瓶颈拖累整体，另一个是开发后，大家都无法持续改进。例如典型的三层架构，很多表，很多代码都是和自身负责的模块无关；一个小改动整个项目需要构建；某个底层库由于各个模块都依赖，到了一定时候，各个模块的视角不同，有的模块想改进这个库或采用完全不同的技术，但动不了了，成为技术瓶颈或死结，所谓的 legacy，重构无望，这时候只有更高层做决定，推倒重来。注意微服务不只是技术拆分，因为代码是可以随便拆分的，而企业或商业运作是不能随意拆分的，拆分需要符合企业体制或商业流程，微服务的系统最终由人来运作，所以不是所有的项目都适用微服务架构。

• 技术解耦（implement independently）/多元化技术（polyglot）：要体现微服务（microservices）的最大威力一定是采用 polyglot，已有的软件解决方案可以直接采纳，管他是 javascript，python，还是 xxx 开发的，管他是自己开发还是他人已经提供，也不管是通过 lib 或者是 api/service。传统的 java 或 .net 包头包尾，一种数据库，一个通用数据层，要承担不同的技术考量，结果自然非最优解。技术解耦带来了技术革命，document db，in memory db，nosql， hadoop，event-based，等等。不仅技术实现最优解，而且达到在不同公司，不同项目中重用，实现快速开发，宏观层面上发挥了最大效益： “Service Endpoint first instead of APIs” 。所以微服务属于八仙过海各显神通，不在是单一的三层架构，从一层（如 serverless），到 n 层，都是可能的。

• 资源解耦（sourcing independently）/游击队战术（coway rule & full stack developers）：标准解释是 - 一个 service 团队的规模不超过两个 pizza。要注意的是游击队战术不是适用所有的企业和商业模式，也不是所有的企业具备游击队的人员结构，所以微服务不是每个企业都适合的。

• 部署&运行解耦（deploy&run independently）/自动化运维（devops）：自动化运维（devops）不是微服务特有的，在现有的项目或系统上完全可以实施自动化运维，也可以看到巨大效益，CI 和 CD 在微服务提出之前已经存在了。但自动化运维是实施微服务的必备技术，拆分和 ployglot 后对自动化运维提出了很高的要求，一堆不同质的东西可以单独部署，升级，同时又要组合在一起无间隙运行，灵活支持 resilient & scalable。容器技术的出现，对微服务所要求的大规模自动化运维提供了必要的技术基础。

Microservices == distributed system

从技术上讲，微服务不是什么新东西， 其架构核心仍就是沿用“模块化”式思路设计整个系统 。纵观开发历史，代码沿着这条线路组织：function -> class -> library -> module -> component/application -> service/system。所以微服务作为架构，仍旧是拆分和集成，和 component-based 或 SOA 是一致的，只是层面不同，微服务不是针对小型软件或者单个项目层面，因为大部分的软件项目还没有等到解耦，拆分，长期演化成为”硬“需求，项目已经结束或者死掉啦。但反之，不同技术实力的团队，不同的项目，不同的地点，不同的时间，重复开发和实现，微服务解耦特性就能把软件的最大价值发挥出来，否则都是在做 silo application/project。所以微服务在政府，大公司或大型项目中推广和应用才能发挥其威力。 微服务应用的本质就是分布式系统 ，所以门槛高，技术点多 - 如何根据商业逻辑进行拆分，拆分后如何对 service 进行桥接和集成，数据拆分后带来的效率以及一致性问题，如何 CI/CD，运行时如何调错。

另外，微服务还包含了开发团队的架构，运维的架构，这是和以往的架构概念非常不同的地方，也是实施微服务可能忽略的地方。 微服务同时锁定了以 service 为导向的开发和运维模式（service oriented development and operation） ，不只是纯技术架构。一上来大家马上关注拆分，个人认为理念要先搞清楚， 自动化运维和团队组织必须先行 ，这是必要条件，同时对现有的单体架构帮助也甚大。对于单体架构的改造我认为首先考虑的应该不是如何完全拆分，而是合并，重用。

微服务的技术栈

上面提到 微服务应用的本质就是分布式系统 ，如果你在 IT 界活的够久，了解分布式一路走来的历程，就会明白“微服务”从技术架构上讲没有什么特殊的新问题，只是技术手段不断翻新。“微服务”那一大堆注册，配置，调用，负载平衡，cluster，分布式日志，追踪等等技术其实是分布式本身要求的。微服务或者分布式的几个技术难点：

• 由于分布，调用变得困难，首先体先在 networking 方面，本地的方法调用，都变成了 RPC，服务的注册和发现是微服务的必备条件，随之而来的还有服务的负载平衡，监控，雪崩处理（circuit break），等等。

• stateless vs stateful：state 对于远程调用是个 bug，必须绕过，所以微服务是以 stateless 为基础的。

• 分布式数据 distributed data：服务拆分的后果是数据也要拆分，那么分布式 transaction，分布式的 join，数据一致性，数据传输等如何处理，都是技术难点。此问题还是尽力避免为宜。

• 性能 performance：分布式是处理提高了 scalability，但带来了众多的系统和网络性能开销，缓存，消息机制是分布式系统设计时必备技术手段。

微服务的老大和先行者是 AWS，可惜它不开源。业界比较全的方案就是 Spring 系列的 Spring Boot & Spring Cloud，另一套是正在兴起的基于容器和 Kubernetes 的 service mesh - Istio。Spring Cloud 虽然是目前最成熟的方案，但几年前刚出笼时，我并不看好，因为相较 J2EE，从技术高度看是开后车或者只是探索阶段，因为 J2EE 已经统一提供了注册，调用，配置，部署，等标准。最近出现基于容器的 service mesh，回归软件基础设施，才是微服务技术的发展方向。

微服务的经验和想法

微服务小结:

• 原来一个项目变成了几十个项目，“技术上”不再是同样的一个东西；
• 拆分依旧是设计的重点，取决于个人理解；
• 开发技术栈加大加深，系统基础性设计依旧是统一的；
• 开发体验下降，对开发者要求提高；
• DevOps 必须先行，无论用不用微服务；
• 微服务不是新鲜事物，也不是一个技术，而是几个东西的统称，核心是分布式系统，具备 4 个特性；

本博客是好几年一路走来的想法，现在更加坚定：

• 云 Cloud （IaaS，PaaS，CaaS 等）: infrastructure，软件部署和运行的物理基础
• 微服务 Microservices ：软件的组织架构
• 自动化运维 Devops ：enabler，软件打包，集成，测试，部署，运维，监控的流程，联系前两者的手段