反模式是随着项目的推进演变而来的，主要的原因，如重大需求调整，但架构没有对应的变化，性能和安全需求对当前架构的硬性改变，团队或组织强行调整技术等。本文将为大家讲解云原生架构中常见的反模式。

庞大的单体应用

如果你有过维护或者开发巨型单体应用的经历，肯定遇到过诸多令人痛苦的问题，比如，git 仓库过于庞大、ide 打开慢、编译慢、应用启动慢、依赖的服务太多……对于新人来说，能够将代码复制下来，并且编译成功，能正常启动应用，那将是极其幸运的事情。更多的情况则是，运维人员至少要花费 1 到 2 周的时间去了解这个庞大的应用，否则基本上无法开始编写代码。这里并不是要排斥巨型单体应用，其还是有适用场景的。我们也不想讨论什么情况下不适合使用微服务之类的话题，这些都需要根据实际情况做出合理的决策。但是，对于大多数业务场景来说，微服务架构是非常合适的。

单体应用“硬拆”为微服务

应用的划分是一套非常科学的方法论。正如庖丁解牛一样，只有了解了系统的原理，摆脱一刀切的思维，我们才能做到游刃有余。最核心的还是领域驱动设计（domain-drivendesign，ddd）的划分思想。

ddd 的本质是根据业务属性将系统划分为不同的业务领域，最简单的如电商系统中的会员、商品、交易和物流等。为了配合这些业务的运行，我们需要一些支持系统，如 cms、社交运营平台等。如果涉及个性化推荐的商业需求，大数据和 ai 平台也是必不可少的。

依据 ddd 的 domain 原则划分子域后，我们会使用 bounded context 来实现这些子域的落地。上契目前，我们可以将 bounded context 理解为微服务应用，多个 bounded context 可以共同支持一个子域，从而共同实现子域需要的业务功能。ddd 提供了非常完善的 bounded context 之间的关联关系和通信机制。例如，最新的 ddd + reactive 模式就是将异步化和事件驱动的设计思想带到了微服务架构设计中。

ddd 的子域主要分为三种类型，分别为核心子域、普通子域和支持子域。其中，普通子域和支持子域就是我们常说的通用类子域，具体业务形态体现为 saas 服务，或者云厂商提供的技术产品，如业务相关的经销存管理系统、crm 管理系统、社交营销平台等，技术产品如应用性能监控、图片识别服务、数据分析平台等。在项目研发的前 / 中期，建议考虑整合第三方或者云厂商提供的普通子域和支持子域服务，将重心放在业务核心子域，不能 因为受到普通子域和支持子域开发进度、特性不完善等问题的影响，而造成核心子域上线延迟、功能缺失等问题，待项目后期再考虑是否自主实现普通子域和支持子域服务。这方面已有不少成功案例值得参考，很多支持核心业务的通用服务伴随着商业项目的发展也取 得了成功，如亚马逊的 aws 云服务。

缺乏自动化能力的微服务

当微服务应用数量较小的时候，我们还能以手动的方式维护系统。但是，当应用数量变得比较庞大时，再采用手动维护的方式已经不大可能，我们需要依靠自动化的方式来 管理大量的微服务应用。应用的自动化管理会涉及很多方面，如编译、部署和监控。目前，大多数 paas 平台和云厂商提供的服务基本上具备自动化能力。通常，我们不用自己开发， 只需要对接即可， 或者只需要进行少量的配置， 或者添加一些相关的监控埋点等。

对于开发来说，市面上已有很多支持测试自动化的框架，比如 ci/cd、iaas、各种便捷的 kubernetes 命令工具洛阳理工附中和服务类 api，如自动化测试环境的 testcontainer、测试数据自动化的 databa rider、模拟 http rest api 的 hoverfly-java 等，都有助于快速完成自动化。但我们认为构建自动化能力的关键在于团队是否有这样的意识，而不是对应的技术产品是否完善。如果团队决定采用微服务架构，那么最好能够提前考虑关于微服务的自动化 能力，统一规划，这样即便在后期面对微服务应用数量激增、技术栈不统一的情况，也不会忙中出错。当开发人员同时投入 3 到 5 个微服务应用的开发和维护时，想要在不同的应用之间快速切换且不出现错误，则是非常困难的。所以一定要铭记，对于微服务来说，自动化的 ci/cd 是最低的要求。

架构不能充分使用云的弹性能力

云计算服务架构主要可划分为三层，分别是 iaas、paas和 saas，如图所示。

云计算服务架构

iaas 位于最底层，提供服务器、存储、网络等服务。这些都属于基础设施，例如云服务器、存储服务等。paas 位于 iaas 之上，是对 iaas 资源的进一步抽象，基本屏蔽了 iaas 层的细节，例如 kubernetes 就属于这一层。saas 位于最高层，直接提供服务及服务对接，例如 openapi 集成、调用阿里云短信发送服务等，都属于 saas 层提供的服务。

从理论上讲，我们最好能直接对接 saas 层提供的服务，至于服务器、存储以及资源扩展，全部交由 saas 厂商负责。对于 paas 层，由于我们需要开发自己的内部应用，会涉及应用部署之类的问题，因此该层的自动化（如资源的自动管理）通常都做得比较好。如果考虑弹性扩容能力，最好是基于 paas 平台进行。iaas 层的弹性扩容是比较难的，不能随意购买云服务器和存储，购买这些资源后则需要进行一系列的工作，如对环境初始化、设置 ops 监控系统、部署应用以及上线应用。

技术架构与组织能力不匹配

应用微服务化之后，会有更多的小团队负责不同的微服务应用，可能需要重新组建管理团队、开发团队和基础设施运维团队，由此可能会带来组织结构和管理方式的调整。

其中的一个变化是团队管理更趋于扁平化。在开发和维护巨型应用时，每个人只会集中于某一个模块。在进行大型应用的需求变更和新特性开发之前，开发人员都会经过一套标准的流程，即评估、任务分解、安排开发进度等。而且开发人员最了解模块，可以保证流程都是可控的，最后经过完善的测试后整体上线。当然，微服务应用也会随着商业需求的变化而调整，但这个过程不再是大团队一起配合、一起上线，更有可能的是，特性的开发和新功能的调整分阶段进行开发和上线。由于在不同的微服务之间存在不同的服务规约，因此可以逐步开发和上线。我们可以将这种分阶段理解为一种“小步快跑”的研发节奏。当然整群抽样，大型应用也可以采用“小步快跑”的方式。

对于开发团队来说，应用微服务化后，每个服务都会变得更聚焦，体量更小。但“麻雀虽小，五脏俱全”，微服务同样要求我们拥有更多的知识。在这个过程中，我们可以寻求团队中其他人的帮助，但这势必会在天亮前离开产生沟通成本，降低研发效率，所以要有能力解决 90% 的问题。另外，微服务化更强调单兵作战的能力。微服务架构是多语言、多技术栈的架构，虽然不需要我们深入了解每一个微服务的编程语言和技术栈，但要求至少掌握相应的开发技术。如 java 程序员切换到 node.js 应用时，不需要了解 node.js 的底层知识（如 v8、eventloop 等），只要理解 javascript 语法、模块管理、promi 和 async/await 等，基本上就可以正常维护一个 node.js 微服务应用了。这些变化可能给开发团队带来新的挑战，至少团队成员需要学习和了解的知识要比以前更多。

为了更好地配合开发团队，基础设施运维团队需要获得更好的 paas 服务（如基于kubernetes 二次开发，或者云厂商提供的 paas 平台）。只有有了充足的保读的英语怎么读证，运维团队才能工作得更快、更好。