系统架构面临的三大挑战，看 Kubernetes 监控如何解决？

Posted 2021-11-04 阿里系统软件技术

随着 Kubernetes 的不断实践落地，我们经常会遇到负载均衡、集群调度、水平扩展等问题。归根到底，这些问题背后都暴露出流量分布不均的问题。那么，我们该如何发现资源使用，解决流量分布不均问题呢？今天，我们就借助三个具体场景聊聊这一问题以及相应的解决方案。

作者｜炎寻
审核&校对：白玙
编辑&排版：雯燕

大家好，我是阿里云云原生应用平台的炎寻，很高兴能与大家继续分享 Kubernetes 监控系列公开课。前两期公开课我们讲到了 Vol.1《通过 Kubernetes 监控探索应用架构，发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异常》。

如何使用 Kubernetes 监控的拓扑来探索应用架构，使用产品采集的监控数据配置告警来发现服务性能问题。今天我们将进行第三讲《使用 Kubernetes 监控发现资源使用，流量分布不均匀的问题》，大家可以钉钉搜索钉群 31588365，加入 Kubernetes 监控答疑群进行交流。

随着 Kubernetes 的不断实践落地，我们经常会遇到越来越多问题，诸如负载均衡、集群调度、水平扩展等问题。归根到底，这些问题背后都暴露出流量分布不均的问题。那么，我们该如何发现资源使用，解决流量分布不均问题呢？今天，我们就借助三个具体场景聊聊这一问题以及相应的解决方案。

系统架构面临的挑战一：负载均衡

通常来说，对于一个业务系统，架构会有很多层，每层包含很多组件，比如服务接入、中间件、存储，我们希望每个组件的负载都是均衡的，这样性能和稳定性都是最高的，但在多语言多通信协议场景下，快速发现以下问题具备一定难度，比如：

• 应用服务器处理的请求是否均匀？
• 应用服务器对中间件服务实例的访问流量是否均匀？
• 数据库各个分库分表实例读写流量是否均匀？
• …

我们在实际工作实践中会遇到的典型场景就是负载不均衡，线上的流量转发策略或者流量转发组件自身有问题，导致应用服务各个实例接收到的请求量不均衡，部分实例处理的流量显著高于其他节点，导致这部分实例的性能相对于其他实例来说显著恶化，那么路由到这部分实例上的请求无法得到及时的响应，造成系统整体的性能和稳定性降低。

除了服务端不均匀场景之外，云上用户大多使用云服务实例，在实践中会出现应用服务各个实例处理的流量均匀，但访问云服务实例的节点出现流量不均匀，导致云服务实例整体性能和稳定性下降。通常在应用运行时整体链路梳理和特定问题节点上下游分析时，会进入该场景。

那么，我们如何快速发现问题、解决问题呢？

针对这一问题，我们可以从服务负载、请求负载这两个方面对客户端、服务端进行问题发现，判断各个组件实例服务负载和对外请求负载是否均衡。

（1）服务端负载

对于服务端负载均衡问题排查，我们需要了解服务详情，对任意特定的 Service，Deployment，DaemonSet，StatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情功能，我们可以看到 Pod 列表部分会列出后端的所有 Pod，在表格中我们列出了每个 Pod 在选择时间段内的请求数聚合值和请求数时序，通过对请求数一列进行排序，我们可以清楚地看到后端的流量是否均匀。

（2）客户端负载

对于客户端负载均衡问题排查，Kubernetes 监控提供集群拓扑功能，对于任意特定的 Service，Deployment，DaemonSet，StatefulSet，我们都可以查看其关联的拓扑，当选定关联关系之后，点击表格化会列出所有与问题实体关联的网络拓扑，表格每一项都是应用服务节点对外请求的拓扑关系，在表格中我们会展示每一对拓扑关系在选择时间段内的请求数聚合值和请求数时序，通过对请求数一列进行排序，可以清楚地看到特定节点作为客户端对特定的服务端访问是否流量均匀。

系统架构面临的挑战二：集群调度

在 Kubernetes 集群部署场景下，将 Pod 分发到某个节点的过程称之为调度，对于每个 Pod 来说，其调度过程包含了“根据过滤条件找候选节点”以及“找最好的节点”两个步骤，“根据过滤条件找候选节点”除了根据 Pod 和 node 的污点，忍受关系来过滤节点，还有一点非常重要的就是根据资源预留的量来过滤，比如节点的 CPU 只有 1 核的预留，那么对于一个请求 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了根据 Pod 和 node 的亲和性来选择，一般是在过滤出来的节点里面选择最空闲的。

基于上面的理论，我们在实践过程中经常会遇到一些问题：

• 为什么集群资源使用率很低却无法调度 Pod？
• 为什么部分节点资源使用率显著高于其他节点？
• 为什么只有部分节点资源无法调度？
• …

我们在实际工作实践中会遇到的典型场景就是资源热点问题，特定节点频繁发生 Pod 调度问题，整个集群资源利用率极低但是无法调度 Pod。如图，我们可以看到 Node1、Node2 已经调度满了 Pod，Node3 没有任何 Pod 调度上去，这个问题对跨 region 容灾高可用，整体的性能都有影响。我们通常在 Pod 调度失败会进入到该场景。

那么，我们该如何处理呢？

对于 Pod 无法调度的问题排查，我们通常应该关注到下面三个要点：

• 节点有 Pod 数量调度上限
• 节点有 CPU 请求调度上限
• 节点有内存请求调度上限

Kubernetes 监控提供的集群节点列表展示以上三个要点。通过排序去查看各个节点是否均匀来查看资源热点问题。比如，某个节点 CPU 请求率接近 100%，那么就意味着任何对 CPU 有请求的 Pod 都无法调度到该节点上，如果说只有个别节点的 CPU 请求率接近 100%，其他节点都十分空闲，就需要检查一下该节点的资源容量和 Pod 分布，进一步排查问题。

除了节点有资源热点问题之外，容器也有资源热点问题。如图，对于一个多副本服务来说，其容器的资源使用分布也可能有资源热点问题，主要体现在 CPU 和内存使用上，CPU 在容器环境中是可压缩资源，达到上限之后只会限制，不会对容器本身生命周期造成影响，而内存在容器环境中是不可压缩资源，达到上限之后会出现 OOM，由于每个节点运行的时候虽然处理的请求量一致，但是不同请求不同参数导致的 CPU 和内存消耗可能不一样，那么这样会导致部分容器的资源出现热点，对生命周期和自动扩缩容都会造成影响。

针对容器的资源热点问题，通过理论分析，我们需要关注的要点如下：

• CPU 是可压缩资源
• 内存是不可压缩资源
• Requests 用于调度
• Limits 用于运行时资源限制隔离

Kubernetes 监控在服务详情的 Pod 列表展示以上四个要点，支持排序，通过查看各个 Pod 是否均匀来查看资源热点问题，比如某个 Pod CPU 使用/请求率接近 100%，那么就意味着可能触发自动扩缩容，如果说只有个别 Pod 的 CPU 使用/请求率接近 100%，其他节点都十分空闲，就需要检查处理逻辑，进一步排查问题。

系统架构面临的挑战三：单点问题

对于单点问题而言，其本质就是高可用问题。高可用问题解法只有一个，就是冗余，多节点，多 region，多 zone，多机房，越分散越好，越冗余越好。除此之外，在流量增长，组件压力增大的情况下，系统各组件是否可以水平扩展也成为一个重要的议题。

单点问题，应用服务只有最多 1 个节点，当该节点因为网络或者其他问题中断，无法通过重启解决时，系统崩溃，与此同时，因为只有一个节点，当流量增长超过一个节点的处理能力时，系统整体的性能表现会严重恶化，单点问题会影响系统的性能和高可用能力，针对该问题，Kubernetes监控支持查看 Service，Daemonset，StatefulSet，Deployment 的副本数，快速定位单点问题。

通过上面的介绍我们可以看到 Kubernetes 监控可以从服务端，客户端多视角支持多语言多通信协议场景下的负载均衡问题排查，与此同时容器，节点，服务的资源热点问题排查，最后通过副本数检查和流量分析支持单点问题排查。在后续的迭代过程中，我们会将这些检查点作为场景开关，一键开启之后自动检查，报警。

目前，Kubernetes 监控免费使用中。点击下方链接，开启 ARMS 即可使用。
https://www.aliyun.com/activity/middleware/container-monitoring

Kubernetes 监控答疑钉钉群（群号：31588365）

解析微服务架构：单块架构系统以及其面临的挑战

概述

多年来，我们一直在技术的浪潮中乘风破浪，扬帆奋进，寻找更优秀的方法来构建IT系统，也一直在积极的学习并观察先进的公司如何以不同的架构方式构建或者优化其IT系统，来积极应对市场的变化，迅速做出响应，从而为客户提供更多的价值。

微服务架构模式（Microservice Architect Pattern）是近两年在软件架构模式领域里出现的一个新名词。虽然其诞生的时间不长，但其在各种演讲、文章、书籍上所出现的频率已经让很多人意识到它对软件领域所带来的影响。到底什么是微服务，当我们谈论微服务时，它代表着一种什么样的含义？微服务适合应用在什么场景下，以及它有什么样的优缺点？微服务和SOA到底有没有区别？在接下来的几部分里，我将为大家揭开微服务的神秘面纱。

不过，在我们开始探讨微服务架构之前，让我们先回顾一下三层应用架构的发展历程并认识一下什么是单块架构应用。

三层应用架构的发展

对于任何一个软件应用系统而言，其构建目标都是为了满足某类用户的需求，即为用户传递价值。一直以来，软件的架构设计是决定应用系统是否能够被正确、有效实现的关键要素之一。架构设计描述了在应用系统的内部，如何根据业务、技术、组织，以及灵活性、可扩展性、可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定价值的方式。

应用的三层架构

现实生活中，“层”这个字的含义，对大家一点都不陌生。我们经常说楼房高多少层，蛋糕有几层等。通常来说，层有好几种定义，但其中最耳熟能详的，莫过于“层”能帮助我们划分出构成某整体事物的，上下相互支撑的的不同部分。譬如说，我们喜欢吃的蛋糕，一般是由三层组成：第一层的蛋糕体、第二层的奶油，和第三层的水果。从顶部至底部，每一层依赖于下一层，从底部到顶部，每一层又支撑着上一层。

在软件架构模式的领域，经过多年的发展，也有了层的概念：

层能够被单独构造；

层具有区别于其他层的显著特点；

层与层之间能够互相连接、互相支撑、互相作用，相互协作构成一个整体；

层的内部，可以被替换成其他可工作的部分，但对整体的影响不大。

以WEB应用程序为例，在WEB应用程序开发的早期，由于受到面向过程的思维及设计方式的影响，所有的逻辑代码并没有明显的区分，因此代码之间的调用相互交错，错综复杂。譬如，我们早期使用的ASP、JSP以及PHP，都是将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起，这是我们通常提到的一层架构。

随着JAVA，.NET等高级语言的快速发展，这些语言为开发者提供了越来越方便的的数据访问机制，如Java语言的JDBC、IO流，或者.NET的ADO.NET等。这时候，数据访问部分的代码逐渐有了清晰的结构，但表示逻辑和业务逻辑依然交织在一起，我们称这个阶段为二层架构阶段。

随着面向对象分析、面向对象设计、面向对象原则、设计模式、企业架构模式等理念以及方法论的不断发展，从为用户提供功能、以及有效组织软件结构的角度考虑，WEB 应用中不同职责的部分逐渐被定义在了不同的层次，每一层负责的部分更趋向于具体化，细致化，于是软件的三层架构逐渐出现了。三层架构通常包括表示层、业务逻辑层以及数据访问层。

表示层

表示层部分通常指当用户使用应用程序时，看见的、听见的、输入的或者交互的部分。譬如，有可能是信息的显示，音乐的的播放或者可以输入的文本框，单选按钮以及可点击的按钮等。通过这些元素，用户同软件进行交互并获取期望的价值。目前的用户接口大部分情况下为WEB方式，当然也可以是桌面软件的形式，例如. NET的WINFORM或者Java的SWING。

业务逻辑层

业务逻辑部分是根据用户输入的信息，进行逻辑计算或者业务处理的部分。业务逻辑层则主要聚焦应用程序对业务问题的逻辑处理，以及业务流程的操作，它是大部分软件系统区别与其他系统的核心。譬如，当用户点击一个按钮后，它可能会触发业务逻辑部分的代码进行运算，生成用户期望的结果。举例来说，在一个电子商务平台中，作为用户，当我们下单购买某个商品后，应用程序的业务逻辑层会对订单如何进行处理，如何计算折扣、如何配送等进行处理。

数据访问层

在用户同应用程序交互的过程中，会产生数据。这类数据需要通过某种机制被有效的保存，并在将来能够被重复使用，或者提供给其他系统。这种机制或者方法就是数据访问层最关注的部分。也就是说，它关注的是应用程序是如何有效的将数据存储到数据库、文件系统或者其他存储介质中。有一点要注意的是，它关心的是对原始数据的操作（数据库或者文本文件等存放数据的形式），而非原始数据的存储介质本身。譬如，在一个电子商务平台中，商品的信息是如何存储，图片的信息是如何获取的等。

三层架构的出现，一方面是为了解决应用程序中代码间调用复杂、代码职责不清的问题。其通过在各层间定义接口，并将接口与实现分离，可以很容易的用不同的实现来替换原有层次的实现，从而有效降低层与层之间的依赖。这种方式不仅有利于帮助团队理解整个应用架构，降低后期维护成本，同时也有利于制定整个应用程序架构的标准。

另一方面，三层结构的出现从某种程度上也解决了企业内部如何有效的根据技能调配人员，提高生产效率的问题。在大环境下，有效的分层能使不同职责的人员各司其职，更聚焦与个人专业技能的发展和培养。三层结构的出现不仅标准化了复杂系统的逻辑划分，更帮助企业解决了如何有效形成技术人员组织结构的问题，因此在很长的一段时间里，它一直是软件架构的经典模式之一。

非三层架构

有些人认为，对于一个WEB应用程序，其被自动地分成了三层架构，因为它有三个分离的部件，如图所示：

这三个部分看起来虽然满足“层”的概念，但它并不是我们所说的软件架构的层。就像我们所说的奶油蛋糕，我们可以在蛋糕的底部加上稳固的底座，在蛋糕的外部加上漂亮的包装盒，但仔细想想，底座可以用不同品牌的底座，可以用纸质材料的，也可以用树脂材料的；包装盒可以用红色的一次性纸袋，也可以用蓝色的带着花纹的铁盒，它们并不是我们蛋糕组成的必须一部分。

浏览器可以独立存在与WEB应用程序之外，WEB应用程序也可以被不同的浏览器访问，因此浏览器不是WEB应用程序的部分。虽然最近几年，在浏览器端，我们可以使用很多JavaScript库或者框架独立开发前端应用，但它的范畴超出了我们目前讨论的三层架构，更多的属于富客户端以及前后端分离的应用。

类似的，数据库服务器也可以独立存在于应用程序之外，因此它也不是应用程序的一部分。虽然有些应用程序的逻辑代码，被设计成必须是在数据库中运行，例如存储过程或者触发器，但这种用法并不推荐，原因是将业务逻辑放在了数据库本身，大大增加了后期维护的复杂度和数据迁移的成本。

单块架构应用：什么是单块架构应用

虽然软件的三层架构帮助我们将应用在逻辑上分成了三层，但它并不是物理上的分层。这也就意味着，即便我们将应用架构分成了 所谓的三层，经过开发团队对不同层的代码实现，经历过编译（如果非静态语言，可以跳过编译阶段）、打包、部署后，不考虑负载均衡以及水平扩展的情况，最终还是运行在同一个机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，我们通常称之为单块架构应用。典型的单块架构应用，莫过于传统的J2EE项目所构建的产品或者项目，它们存在的形态一般是WAR包或者EAR包。当部署这类应用时，通常是将整个一块都作为一个整体，部署在同一个WEB容器，如Tomcat或者Jetty中。当这类应用运行起来后，所有的功能也都运行在同一个进程中。

类似的，基于Ruby On Rails的单块架构应用，一般逻辑上分为控制器层、模型层以及视图层，同时代码存放在遵循一定层级结构 的目录中。当部署这类应用的时候，通常是使用SSH或者其他一些工具，如Capistrano将整个目录部署在Passenger或者其他WEB容器中。当这类应用运行起来后，所有的功能也都运行在同一个进程中。

因此，对于单块架构应用的定义，其实是基于分层软件架构设计的系统基础之上，从部署模式、运行模式角度去考虑的一种定义方式。

单块架构应用：优势

易于开发

对单块架构的应用程序而言，开发方式相对较简单。首先从概念上，现有的大部分工具、应用服务器、框架都是这类单块架构应用程序，容易理解而且为人所熟知。如果从实践角度出发，现有的集成开发工具比较适合单块架构的应用程序，像NetBeans、Eclipse、IDEA等，它们都能够有效加载并配置整个应用程序的依赖，方便开发人员开发、运行、调试等。

易于测试

单块架构应用程序也非常容易被测试，因为所有的功能都运行在一个进程中，启动集成开发环境或者将发布包部署到某一环境，一旦启动该进程，就可以立即开始系统测试或者功能测试。

易于部署

对单块架构的应用程序而言，部署也比较容易。实际上，由于所有的功能最终都会打成一个包，因此只需复制该软件包到服务器相应的位置即可。当然，部署的方式可以有很多种，最简单的可以使用SCP远程拷贝到指定的目录下，当然也可以使用某些自动化的工具来完成。

易于水平伸缩

对单块架构的应用程序而言，水平伸缩也比较容易。实际上，由于所有的功能最终都会打成一个包，且只能运行在一个进程中，因此单块架构的水平伸缩，更确切的理解其实是克隆，即新建一个服务器节点，配置好该节点的运行环境，复制软件包到相应的位置，运行改应用程序。当然，必须要确保负载均衡器能采取某种分发策略，有效的将请求分发到新创建的节点。

单块应用架构：面临的挑战

随着最近几年互联网行业的迅猛发展，随着公司或者组织业务的不断扩张，需求不断的增加以及用户量的不断增加，单块架构的优势已逐渐无法适应互联网时代的快速变化，面临着越来越多的挑战。譬如说，一方面，随着业务的扩大，如何为用户提供可靠的服务，如何有效处理用户增多后导致并发请求数增多，导致的响应慢的问题，以及如何有效解决用户增多后带来的大数据量的问题等。另外一方面，随着公司或者组织业务的不断扩张，需求不断的增加，越来越多的人加入开发团队，代码库也在急剧膨胀。在这种情况下，单块架构的可维护性、灵活性在降低，而测试成本、构建成本以及维护成本却在显著增加。

维护成本增加

随着应用程序的功能越来越多，团队越来越大，相应的沟通成本、管理成本、人员协调成本必然会显著增加。譬如说，对于使用Java编写的中型应用而言，当代码量为几万行时，可能只需要几人左右的团队维护。当代码量上升到几十万行级别时，可能需要几十人甚至是上百人的团队。

另外，随着应用程序功能的增多，当出现缺陷时，有可能引起缺陷的原因组合就会比较多，这也会导致分析缺陷、定位缺陷、修复缺陷的成本相应增高，也就意味着缺陷的平均修复周期可能会花费更长时间。

随着代码量的增大，在开发人员对全局功能缺乏深度理解的情况下，修复一个缺陷，还有可能引入其他的缺陷，在自动化测试机制不完善的情况下，很可能导致该过程陷入“修复越多，缺陷越多”的恶性循环。

持续交付周期长

随着应用程序的功能越来越多，代码越来越复杂，构建和部署时间也会相应的增长。在现有部署流水线稳定工作的情况下，对单块架构应用程序做任何细微的修改以及代码提交，都会触发部署流水线，对整个应用程序进行代码编译、运行单元测试、代码检查、构建并生成部署包、验证功能等，这也就意味着流水线的反馈周期变长，单位时间内构建的效率变低了。

另一方面，团队人员的增多，部署流水线运行的时间增加，开发人员能够提交代码的时间窗口就相应减少，（因为流水线运行的过程中，是禁止提交代码的），可能出现长时间等待代码提交，却无法提交的情况，极大破坏了团队的灵活性并降低了团队工作效率。几年前，我曾经工作在一个50万代码行的单块架构应用上，整个应用由一个50人左右的分布式团队负责。通常情况下，从开发人员提交代码到运行单元测试、构建发布包、运行功能测试、标记为可发布状态大概需要40分钟，时间稍微有点长，但团还能忍受。关键的问题是开发人员通常都是集中在下午3点左右，完成一定功能的情况下提交代码，结果就导致3点至5点那个时间段，成了代码提交的瓶颈，极大影响了该应用的持续集成和构建的效率。

新人培养周期长

随着应用程序的功能越来越多，代码变得越来越复杂的同时，对于新加入团队的成员而言，了解行业背景、熟悉应用程序业务、配置本地开发环境，这些看似简单的任务，将会花费更长的时间。我曾经有个朋友，在加入一家世界500强的知名IT公司后，被安排到了一个百万级代码的产品组里。他花了将近1个月的时间来熟悉产品文档、配置开发环境后，才在本地成功的运行起了这个应用。在他从事这份新工作的头一个月里，我们好几次聊到他的新工作，得到的答案都是一样，“看文档，装环境”。对个人而言，花一个月时间来配置本地开发环境，其中的滋味和感受大家可想而知，我估计人世间比这更痛苦的事情也没几件了。而对公司或者部门而言，本期望员工花费数天就能配置好的环境，却花了一个月才能完成，这更是极大的浪费。更有甚者，在第一次配置完开发环境后，好几年都不愿意再升级或者重装系统，真是一招被蛇咬，十年怕井绳。

技术选型成本高

传统的单块架构系统倾向采用统一的技术平台或方案来解决所有问题。通常，技术栈的决策是在团队开发之前经过架构师、技术经理慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具。随着应用程序的复杂性逐渐增加以及功能越来越多，如果团队希望尝试引入新的框架、技术，或者对现有技术栈升级，通常会面临不小的风险。

另一方面，互联网行业不仅市场变化快，而且技术变化也快。譬如，短短几年几年时间，光前端JavaScript的框架，就出现了好几十个，从早一点的Backbone、Ember到AngularJS、Ractive等等。类似的，后端的框架、工具等也是层出不穷，有兴趣的朋友可以参考下ThoughtWorks的技术雷达(该技术雷达是ThoughtWorks对业界技术、工具、语言等发展趋势的分析以及预测报告)。因此，对单块架构的应用而言，初始的技术选型严重限制了其将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架，没有完备的功能测试集，很难平滑的完成替换，而且系统规模越大，风险越高。

可伸缩性差

如果应用程序的所有功能代码都运行在同一个服务器上，将会导致应用程序的扩展非常困难。如果迫切的需要扩展，那么垂直扩展可能是最容易的（钱不是问题）。在大多数情况下，如果舍得砸钱上IBM的服务器、Oracle的数据库或者来自EMC的存储设备，不用改变一行代码，整个世界都变好了。不幸的是，伴随着业务的增长，数据的增长，垂直扩展会变得越来越吃力，成本越来越高。这也是为什么在业很多公司开始尝试使用开源，放弃这些昂贵的IOE产品的原因。这下明白为什么近几年去IOE的呼声越来越高了吧。

当考虑水平扩展时，通常的做法是建立一个集群，通过在集群中不断的添加新节点，然后借助前端的负载均衡器，将用户的请求按照某种算法，譬如轮转法、散列法或者最小连接法等合理的将请求分配到不同的节点上。但是，由于所有程序代码都运行在服务器上的同一个进程中，会导致应用程序的水平扩展成本非常高。譬如说，如果应用程序某部分的功能是内存密集型的，如需要缓存大量数据，而另外一部分功能是CPU密集型的，如需要进行大量的运算，那么每次实施水平扩展，运行该应用的服务器都必须有足够的内存和强劲的CPU来满足需求。因此，鉴于每个服务器都要提供该应用系统所需要的各种资源，基础设施的整体花费可能会非常高。当然，如果某些节点保持状态，如用户登陆后的会话信息等，更增加了水平扩展的难度。

构建全功能团队难

最后，非常微妙的是，随着应用程序的功能越来越多，代码变得越来越复杂，其应用程序的复杂结构也会逐渐映射到研发团队的结构上。康威定律指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构。单块架构的开发模式在分工时往往以技能为单位，比如UX团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。譬如说，用户体验工程师（UX）更专注负责用户接口部分，业务层开发者则负责建立服务器后端的业务逻辑，数据库工程师和DBA们更关注数据访问组件和数据库。鉴于这些问题，随着时间的推移，不仅代码越来越难以管理，其对团队结构的影响也越来越明显。

综上所述，随着业务的不断扩大，需求功能的持续增加，单块架构已经很难满足业务快速变化的需要。一方面，代码的可维护性、扩展性、灵活性在降低；而另一方面，系统的测试成本、构建成本以及维护成本却在显著增加。因此，随着项目或者产品规模的不断扩大，单块架构应用的改造与重构势在必行。

总结

互联网时代的产品通常有几类特点：

创新成本低、需求变化快，用户群体庞大，它和几年前我们熟悉的单块架构应用有着本质的不同。随着市场变化快、用户需求变化快、用户访问量增加的同时，单块架构应用的维护成本、人员的培养成本、缺陷修复成本、技术架构演进的成本、系统扩展成本等都在增加，因此单块架构曾经的优势已逐渐无法适应互联网时代的快速变化，面临着越来越多的挑战。

---

感谢郭蕾对本文的策划和审校。

---

回复关键词查看对应内容：

React | 架构师 | 运维 | 云 | 开源 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员 | 实践 | 物联网 |

---

如果想要评论本篇文章，想看下其他读者都有什么话想说，欢迎点击“阅读原文”参与讨论。