我看微服务(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,软件打包,集成,测试,部署,运维,监控的流程,联系前两者的手段
0%