反模式是随着项目的推进演变而来的，主要的原因，如重大需求调整，但架构没有对应的变化，性能和安全需求对当前架构的硬性改变，团队或组织强行调整技术等。本文将为大家讲解云原生架构中常见的反模式。
庞大的单体应用
如果你有过维护或者开发巨型单体应用的经历，肯定遇到过诸多令人痛苦的问题，比如，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、测试数据自动化的 Database 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 语法、模块管理、Promise 和 Async/Await 等，基本上就可以正常维护一个 Node.js 微服务应用了。这些变化可能给开发团队带来新的挑战，至少团队成员需要学习和了解的知识要比以前更多。
为了更好地配合开发团队，基础设施运维团队需要获得更好的 PaaS 服务（如基于Kubernetes 二次开发，或者云厂商提供的 PaaS 平台）。只有有了充足的保证，运维团队才能工作得更快、更好。
更多信息
《阿里云云原生架构实践》由阿里云官方出品，阿里云智能总裁张建锋、阿里巴巴首席技术官程立联袂推荐；从设计原则、模式/反模式、技术选项、设计方法、行业案例等多个维度全面总结阿里云云原生架构的方法论和实践经验。
现在开放 5 折限时优惠，可直接点击https://item.jd.com/13295448.html购买。
