2011-2012 年,我所在的团队正在给某国字号企业交付一个集团级的企业应用,这个应用覆盖了除 IaaS 之外的整个上层,层级和宽度上来说都算得上是个大家伙了。在当时,这个项目有几个新鲜的点,例如硬件全部采用通用的 x86 刀片服务器,全部基础软件都使用了开源软件——例如 LAMP、Nginx、MongoDB(是的你没看错,就是 MongoDB),使用 Java、PHP、ASP.NET 等多种平台的多个厂商协作交付;除此之外,还设计了和当时大行其道的 SoA 不太一样的一种架构,这个架构有几个特点:
总的说来这次交付是相当成功的,然而无损创新是不太符合历史规律的,这种架构带来的问题同样挠头:
回到《灾难》一文,其中提到的很多更加具体的点,摘抄几点,一起休闲一下。
20 名工程师组成了维护 50 项服务的小组。一人负责一项服务还不够!:我一直认为,微服务是一个向现实妥协的过程,这个现实应该是全面的,它不仅是业务的现实、也是团队能力的现实,这个语境下所提倡的全能小团队,其能力虽然宽泛,但即使是业务软件也是有其服务上限的,不尊重业务负载和不尊重团队负载,并没有什么区别。量入为出是个基本要求。
Another smell was when someone told me that deploying a new feature in service A also needed a deployment — at the same time — in service B.(有人要求我把一个新功能同时部署到两个不同服务之中):这个例子很有代表性,这里的 Someone 同时是 Service A 和 Service B 两个不同服务的所有者或者部分所有者。所以这一点就面临几个问题:
与仅仅在 IDE 中查看一个项目不同,人们需要一次打开多个项目才能了解所有这些混乱的情况。:其实即使是一个单体应用,只要它规模太大,在外人来说也是很难突然就能够 “make sense of all that mess” 了——别人的代码在功能和非功能层面满足服务要求,没有在边界外造成不良影响,按照契约进行开发和测试,根据讲定的边界做好各种限制各种观测,为啥非要把手伸那么长呢,是职责不清还是拆分有误?
Mobile developers not developing a feature before it was in a development environment or backend developers who wanted to try their service didn’t break any business flow. It was also problematic if someone wanted to test the whole flow in a mobile app before production.:这个问题涉及到的是依赖服务之间的协作开发的问题,实际上所有不同实体之间的调用,不管是内部的函数调用、还是古代的 COM+、CORBA,后来的 WebService/RESTful 等等,都面临同样的环境和上下游依赖问题。至于后续的若干的问题,实际上都是全局角度上的微服务治理问题——其实不管有没有微服务,协作单元多了一定会出现这种情况,像 Grafana Stack、ES Stack、Skywalking 等观测技术,以及 Service Mesh 等的网格技术,都是为了解决这样的难题的。十二要素、云原生等方法也给出了相对具体的设计、部署和运行方法的支持。
这个——非常特别同意。
这个其实应该属于典型的人祸了,到现在应该没人会认为共享数据库的多个进程能够称之为微服务了。
Suddenly, you have your “API gateway” being a single-point-of-failure — because people find it easier to handle authentication in a single place — and with some unintended business logic inside it. Instead of having a monolith getting all of the traffic, now you have a home-made Spring Boot service getting all of it!:网关和服务网格这样的产品,发展下来经常会扩展成具备大量功能的超级工具,这给人一种联想——上了工具之后写写配置就有功能用了这实在是太棒了。然而 Java 开发者或者 YAML 工程师都会知道,配置 这事太难了,以至于出现了 OPA、PIPY 这样直接让配置工程师撸代码的“反潮流”工具。
事实上采用一个开源/第三方软件或者库,因其规模不同,对应的评价工作量是完全不同的,尤其对于 Kong、Istio 这样的大家伙来说,比起“用不用”的问题来说,“用多少”和“怎么用”的问题可能更加复杂,动辄“全面拥抱”可能是一个非常冒险的行为。
这个似乎是服务间调用的普遍情况,我不确定这是微服务的锅。
在实施转型或者说改造的过程中,难免会遇到这样那样的问题,然而微服务其实并没有什么特别的——就特别多、特别碎。如果能在全局层面做好观测、做好治理,练好基本功,让每个服务都能各司其职又不互相妨碍,是不是微服务又能有什么关系呢。微服务是为业务服务,同现状和解的,抛开目的和现实,单纯为微服务而微服务,很可能除了话题,一无所获。