为什么导入微服务架构很容易撞墙?

Donald

客座文章作者:Fred Chien(钱逢祥),Brobridge

一次了解微服务架构的各种技术议题和陷阱

微服务架构像是一团迷雾,伸手不见五指,无论怎么做好像都是错的,一不小心就撞上了藏在雾中的墙。在一知半解下,有人选择导入容器平台(如:Kubernetes)走一步算一步,有人选择观望或是先了解到底有哪些事需要「超前部署」。但不管怎么下这盘棋,不管走了多少步,永远看不透这团迷雾,不知道这盘棋的终点在哪。

尤其是一些已经花了钱做基础设施的客户比谁都慌张,来找我们时,都希望我们能帮忙指出一条可行的路。虽然就算指出来,仍然是一条不容易走的路,但总比在黑暗中乱摸索,更让客户觉得安心。

本文将试着整理出整个微服务架构中,各种关键技术议题、被忽略的议题,希望能让欲导入微服务架构的企业和组织,可以了解这条路上将要面临的考验。

大多数企业已经做了什么?

可以说,许多企业在基础设施上,已经具备了实现微服务架构的基础(例如:Kubernetes、CI/CD等)。撇除开发规范、组织政策改造等议题,在部署和维运层面上已经多半没有问题,接着要面对的是应用开发、服务改造以及落实架构等议题。

在应用开发上,首先是选择一个够轻量的应用程式框架,来因应微服务多而散的部署需求。在这种考量下,根据企业原先习惯的语言而有不同的选择,例如习惯 Java 的企业,通常会选择 Spring Boot。

另一方面,从架构设计来看,微服务思维的服务拆分就是一个明显要解决的问题。因此,许多企业亦开始将领域驱动设计(DDD,Domain-Driven Design)当作唯一手段,以梳理既有业务、拆分既有服务。

从各方面来看,似乎一切都已经完备。

大家到底遗漏了什么?

服务逻辑拆分之下、应用程式框架之上仍有许多议题待解决(图中只是部分)

乍看之下,多数欲投入微服务架构的企业,在技术选型上,似乎下有应用程式框架,而上有领域驱动设计等方法,理论上在微服务之路上,应该走得顺遂。然而,市场上仍不断听到有企业导入失败,或是走到最后走不下去的声音。

事实上,在「应用程式框架」与「服务逻辑拆分」之间,仍然缺少许多东西,如图中红色区块所示。而缺少的部分,才是微服务架构设计与实作中,最复杂也是陷阱最多的地方。

要有认知,分散式架构下的各种设计,与过去的思维并不太一样,以往我们可以在单一资料库、同个记忆体中实现的功能,都会被搬出到不同的机器、节点上,然后跨网路协同作业。这对许多开发人员来说,都是全新的领域、全新的设计模式,旧有的经验甚至一时无用武之地。

以过去经验去看待微服务架构,很容易到后来会发现,绕了一大圈搞了半天,结果只是做了一堆分散式的单体架构,没有得到微服务的半点好处,甚至是招来许多难以解决的问题,掉入难以翻身的陷阱。

忽略了种种议题后,要把微服务架构正确的建构出来,几乎是不可能的事。

资料解耦是迷雾中的起点

微服务架构设计议题包括逻辑拆分和资料解耦

尽管引入许多设计模式,或是采用领域驱动设计(DDD)来解耦服务,多半重心仍都在讨论应用逻辑的拆分,尤其若是缺少了相关技术的知识,通常大多数人面对资料层的解耦工作,都会选择忽略或是放弃。这也是为什么很多人找了顾问来导入 DDD 之后,一旦进入技术实作,要不就是做出来成效不好,不然就是实作不出来。

要知道,资料是应用中最具有「重量」的部分,唯有资料解耦才能真正实现微服务架构的服务拆分。若我们在做 DDD 或服务拆分工作时,迁就资料而做了错误的聚合,就无法正确的实现微服务架构,最终导致失败。

至于资料解耦,一定要做高风险的拆表拆库吗?不需要。若想要理解资料解耦的真正目的,以及解耦后的资料管理方法,可参考旧文:CQRS 的神奇把戏:微服务资料解耦

在一些 DDD 的书籍之中,通常都会提及如 CQRS 这类技术设计模式,协助 DDD 中的领域边界进行资料交换或聚合。只不过,很多人只将 DDD 当作纯理论的方法看待,而忽略了这些书籍中提及的技术议题,导致徒有形,而缺乏实际的处理手法。

资料一致性是一切核心

围绕在资料一致性上的议题

基本上,微服务架构就是分散式系统的设计,这意味着服务状态、资料都不是中心化的存在,除了要考虑服务间状态一致性的问题,也要考虑资料同步、分享等议题。但面对不同的应用,资料一致性的要求也不同,有些应用需要绝对的一致性,有些应用可以接受强一致性,而有些应用场景只要实现最终一致性就可以。

面对不同的资料一致性需求,解决方式也相当多元,主要议题围绕在分散式资料管理、状态及物件生命周期管理、分散式事务或有状态服务的身上。

唯有妥善设计这些管理机制或进行适当的整合,才有可能在不同应用下,实现微服务架构。只要过于偏重特定的设计模式,或是在不恰当的情境下采用错误的方法,都会导致许多后遗症,甚至失败。

错误的设计,可能会导致无法解耦的资料库、难以扩展的单体式架构,甚至面临效能冲击、维护性问题。

搞清楚低延迟需求如何满足

理论上,分散式架构无法解决的问题就是延迟,由于程式逻辑、资料分散,导致大多数任务都需要跨服务沟通、同步和交换状态,这意味着延迟的状况总会发生,只是目标应用接受延迟的程度为何、是否能接受而已。

虽然现在的电脑、网路效能和速度都非常快,这些延迟都不是使用者可以明显察觉的状况,对于大多数应用都是可以接受的。但如果你的应用无法接受这些延迟,需要更极端的即时需求,这时就要依赖有状态服务的设计。

只不过,有状态服务在扩展能力及容错能力上并不好,很容易变成效能瓶颈和稳定性的缺口,伴随而来的单点故障、分散式单体架构问题,都是陷阱。因此如何解耦、优化有状态服务,最小化其运作风险,就是关键。这时,懂得设计状态管理机制和事件排程机制,来实现具有扩展性、又高吞吐量的低延迟需求,就是一件不得不弄清楚的事。

痛苦的开发人员没有三头六臂

待实现的各种微服务议题

许多开发人员原本期望应用程式框架能够有完整的解决方案,但现实是仍有一大段路,需要由个开发者自行解决,尚未有一个终极且完整的解决方案存在。

另外,虽然有一些开放原始码项目,能部分解决或涵盖一些议题,但因为这些项目的不同发展背景,所以其出发点和着眼点也不尽同,很多不一定能满足各企业的需求,甚至仍然需要客制化和自行维护。更多还是要依赖着开发人员的经验和能力,才能把所需的微服务机制实现出来。

但种种议题每一项都不容小觑,一般企业的应用程式开发人员,若要投入任何一项议题,都得花大量精神和人力,很可能无暇再照顾应用程式的开发。尤其是,这种种机制的稳定性和扩展性,是微服务架构能否运作顺畅的关键,若不好好设计和维护,最终结果可想而知。

这还没有提到,让初入微服务架构的开发人员,在一知半解下尝试完成这些关键机制,会有多高风险。对于原本专心于应用程式逻辑的开发人员来说,也是一件痛苦至极的事。

到底如何解决这些议题和避开陷阱?

从基础机制之上,解决分散式资料和状态管理以满足服务解耦的需求

由于资料一致性议题是微服务的核心,所以支撑各类资料一致性的机制,是我们要解决的重中之重,由此下手是最佳的部位。接着,解决大部分资料议题后,再进一步扩展处理服务拆分的技术性问题。

在这种导入途径下,引入 CQRS、分散式交易机制、物件状态及生命周期管理机制和事件排程机制,就是技术实现的关键核心。而于此之下的事件驱动、通讯机制议题,则是不用太过担心,可以透过妥善的教育训练或传统的解决方案,即可满足。

最后强烈建议

如果您到现在对于本文所提及的种种议题和设计模式,仍感到不太熟悉甚至听都没听过。建议您先停下脚步,在还没出更大问题之前,先理解这些议题背后的意义与解决方法之后,再继续您的微服务之旅。

本文资料,来源皆参考自Brobridge的微服务架构设计教育训练课程,如果想要了解更多关于微服务架构设计的议题,可以与我们联络。若对特定微服务元件,或是微服务元件套装感兴趣,也欢迎与我们洽询。

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

阅读 132

布道者,Linux基金会(LFAPAC)

101 声望
388 粉丝
0 条评论

布道者,Linux基金会(LFAPAC)

101 声望
388 粉丝
宣传栏