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

客座文章作者：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微信公众号。