架构演化发展历程 （1）

欢迎访问网易云社区，了解更多网易技术产品运营经验。

1.4 架构演化发展历程

目前，互联网企业随着业务的发展不断前进。因此，不同的阶段有不同的需求，所以 需要使用不同的方法来聚焦不同的目的。比如初创型的企业需要抓住合适的机遇快速进行 原型验证，证明大的方向没问题才有可能进一步发展。因此技术一般是为了满足业务的发 展和验证而设计，只要保证共用的组件能够复用就可以。只有随着业务的进一步发展，组 织架构及人员的规模越来越大，企业才有机会发展成中型或独角兽公司。然而协作人员数 量的增长也意味着新的问题，一般而言，只要企业的人员规模超过 150 人，就会带来极大 的管理成本提升。在这一阶段，技术不仅需要和产品进行更充分的结合，还需要规范化和 工程化操作。当规模再次扩大的时候，如果只是简单的人力堆积，协调性问题是无法解决 的，企业需要更高效的架构才能支撑和反哺业务的发展，工具和流程需要更加自动化才有 可能保证业务的持续发展，边际效应非常明显，同时挑战也更大。

总之，在任何阶段，技术的演进都是一个非常重要的过程，这一点在以技术为导向的 公司尤为凸显。技术超前就有可能成为先行者，技术落后就有可能导致企业发展缓慢，机会丢失。

无论是个人开发者还是技术公司，如果目的是持续运行和发展，就需要一套良好并固 定的制度，同样，在技术上，团队的持续前进离不开项目的工程化思维。开发、测试、发 布的软件生命周期的高效管理必须依赖工程化，它是研发协作与云端运维的基础。这里面 包括许多问题，需要技术人员去解决，比如：追求技术的先进或业务需求的合理性评估， 可能是很多公司技术管理需要根据组织架构权衡的问题。一般来讲，任何从零起步的公司 都会经过不同的技术发展阶段，包括简单的初创期、快速增长期及分布式的服务化架构阶 段。每个阶段对应不同的产品和业务需求，技术承担不同职责，需要技术人员来决策，尤 其是架构师需要思考这些问题。

1.4.1 初创期架构

创业公司在开始新业务的时期，基本处在试错或原型验证阶段，这个阶段更多是关注 业务的本身是否有前景或商业模式，而不会把非常多的精力放在技术的系统架构上，尤其 是对于非技术型或不确定型的项目立项阶段。尽管很多技术人员也预料到前期需要很多时 间去好好设计系统，才能保证支撑后续可能的业务快速发展，但往往由于时间成本或人力 等原因而无法很好地执行。

一般来讲，创业型的项目对时间的要求非常苛刻，需要在 3 到 6 个月时间内完成系统 的上线，否则有可能由于业务无法快速上线验证，导致无法获取相关的原始数据进行下一 个目标验证，更严重的有可能造成资金链的断裂。罗马不是一天建成的，因此这个阶段会 使用相对简单的架构方式来进行设计，本节先从最主要的几点进行说明，更详细内容请参 考第 3 章。

单体架构

对于创业型公司来说，由于人才、技术、资金等重要因素的影响，同时，技术人员为 了配合产品的需求，会采用最简单的架构来完成最原始阶段开发。根据我们接触的不少用 户反馈，有些企业考虑成本因素，甚至只使用一台服务器或者容器服务。另外，传统官网、 论坛等应用，由于早期的设计采用了单体架构来实现，只需要一台服务器或容器来服务即 可。对于其他的应用服务器、数据库、静态文件等资源，也是部署到同一台服务器或容器 上来服务。最简单的架构模型如图 1-11 所示。

图 1-11 最简单的架构模型

对于早期的单体应用，应用服务+数据库服务基本上就组成了最原始的架构模型，技术 人更多会考虑技术的选型，包括编程语言、版本管理、数据库的类型等。比如 PHP 的开发 者选择 PHP+MySQL，Java 的开发者采用 Tomcat+MySQL 等开发方式。

服务器分离 

根据线上运行经验，一般的业务的类型，如果每日的用户访问量在百万级别以内，只 要进行简单的 Web 应用性能参数调优、数据库索引优化等，基本上就能保证服务的稳定运 行。当然，随着访问量的不断增加，部署在同一台服务器上的应用及数据库服务，会造成 服务器的 CPU/内存/磁盘/带宽等系统资源竞争，从而相互影响。显然很容易出现性能瓶颈， 如果这台服务器出现了宕机或无法恢复的错误，就有可能导致全站不可访问或者数据丢失 等情况，后果非常严重，因此大部分产品会将 Web 应用服务器和数据库服务器进行物理分 离，独立部署，相互热备提供服务，只需要增加很少的成本，就能解决对应性能和数据的 可靠性等问题。

初期由于各种条件存在，不能很好地进行新项目前景的预见，技术人员如果能在最小 成本的情况下保证架构的合理性，还能很好地服务产品功能需求，甚至只要在部署架构上 稍做调整，就可以防止出现灾难性的问题，这其中也包括很多技术架构上的考虑。

业务模型 

一般而言，现阶段的业务比较简单，产品也比较单一，业务会随时根据其运营数据进 行调整，因此，这时需要技术人能够较好地把不同的模块分离出来，对于偏业务相关的功 能，需要有较好的心态接收随时变化的不确定性，对于后续可能复用或大量依赖的工程， 需要进行较好的设计，否则可能在业务爆发时导致业务开发的进度越来越慢，甚至阻碍业 务的发展，造成业务时常中断。即使有人力或时间来对系统进行重新设计，也会令技术人 员产生抵触心理，同时也会引入较高的风险。因此，基于云原生应用的设计模式在最基础 的阶段对架构也有很大的作用，包括考虑如何使用云的弹性，将不可变优势融合到系统的 设计中。合理的业务模型分界也是确保后续能发展的重要步骤之一。

总而言之，在早期项目原型验证或者快速试错阶段，采用单体架构具有很大的技术优 势，产品的想法也在项目的初始阶段就能进行比较好的迭代开发，发布和部署也比较灵活。 然而，随着业务的增长，如果架构还是一成不变的话，带来的技术风险就越来越高，比如， 代码行数的增加影响技术人员的学习成本、业务的变更速度、业务的可靠性、安全性及工 程变大后的发布效率等，每次修改都必须反复测试，否则全站随时可能不可用，导致业务 中断或者丢失市场的机会。因此，这部分的技术债务必须在业务快速发展的同时，进行技 术架构的改造，使其能保证后期业务的支撑。所以，除了业务的发展判断外，对开发人员 的技术能力储备和架构远见判断也将成为考虑的事情之一

1.4.2 快速成长期架构

接下来，初创公司随着业务的进一步发展，当 DAU 达到十万的时候，通常是最关键 的时刻，既要保证业务的稳定运行，又要进行产品的快速迭代。到了这个阶段，由于业务 模式得到了一定的验证和反馈，有可能会出现很多竞品或友商。一方面，随着风险资本的 注入，会依赖更有质量的数据进行发展运营，另一方面，竞品的出现又导致了市场的加速 前进。因此，能否在这个阶段保证业务与技术的和谐发展，是考验架构是否足够灵活的指 标之一，同样，本节主要说明几点，更详细内容请参考第 4 章。

前端加速优化 

首先基于浏览器端应用或者移动端应用，随着请求的不断增加，偶尔会看到 Web 服务 出现性能瓶颈导致请求变慢或者失败。除去服务器本身的配置低外，更有可能由于架构设 计或分离的原因，大量的 Web 并发请求被堵塞或者变慢，原因无非是服务器的 CPU、磁盘 I/O、带宽竞争激烈，导致相互影响。这时候我们就需要对架构进行前后端分解，合理配置 或转发请求，如果是前端的服务请求来不及处理或者有瓶颈，可以将图片、JS、CSS、HTML 及应用服务相关的静态资源文件存储通过 Nginx 本地代理或者对象存储服务来进行物理加 速，使用不同的域名来转发请求，并通过 CDN 将静态资源分布式缓存在各个节点实现“就 近访问”，主动或被动刷新 CDN 的缓存来加速前端服务。如果是后端的动态请求压力过大 或者有热点服务，可以把无状态的后端的服务再进一步水平扩展满足业务分担，有状态需 要判断是否能通过垂直扩容来服务，否则只能进行代码、架构设计或者业务规划的调整来 优化。一般而言，通过将动态请求、静态请求的访问分离（“动静分离”），能有效解决服务 器在 CPU、磁盘 I/O、带宽方面的访问压力，当然，这需要在架构设计时采用一些方法来进行调整。

水平扩展 

在上节中提到垂直扩容能解决部分的问题，但由于业务和流量的快速增长及垂直资 源有限，不同的应用场景需要依赖不同的策略分流，比如长连接的应用会依赖于 4 层的 网络连接，互联网应用通常采用 7 层的模式来完成，甚至在游戏场景中，依赖 UDP 进行 通信。为了更多地分担服务器的压力和保证业务的高可用，负载均衡技术通常是这个阶 段解决问题的一个方法，通过增加多台后端服务器就可以实现分流的功能，分流设计也 面临很多原则与技巧，比如分流的路径、权重等，负载均衡承担的角色也决定了后端的应 用架构，比如无状态化设计才能实现水平扩展，另外还要考虑业务是否有亲缘性，同时在 后端服务出现异常的情况下，自动进行健康检查，异常的服务能及时进行下线操作，快速 失败。

数据库及缓存优化 

数据库和缓存配合使用是解决后端结构化数据与非结构化问题的有效手段，根据不同 的场景，要明白哪种数据使用结构化数据合适，哪种数据使用非结构化数据更合适，以及 哪种方式在保证性能较好的情况下成本又可以接受。同时，如何在数据库和缓存之间进行 过渡也是需要考虑的，比如数据在更新的时候，如何保证缓存的一致性，如何保证热点数 据一直被访问，提高缓存的命中率等。另外，当大量用户访问不存在的数据时，也有可能 导致后端的压力非常大，甚至有可能造成雪崩效应。

每种服务独立承担对应的功能，各司其职，并且根据应用的特性区别提供不同的服 务能力，比如应用服务器提供用户的接入服务，数据库服务专门承担结构化数据的存储， 缓存承担或非结构化数据（KV 值对）的存储等，如果要提供搜索的功能，还需将数据进 行分词、索引、检索等，不同服务器根据业务的功用需求来提供对应的服务，如图 1-12 所示。

在这个阶段，除了必须保证满足业务的功能型需求，还要更多考虑非功能性需求，比 如，通过前端负载均衡提供业务分流的能力，根据用户的特征进行不同的流量转发；数据 库提供主备的能力，两者之间通过数据同步进行数据备份，当主数据库发生故障后，应用 可以自动切换到备份的服务器来为用户提供服务；在用户体验方面，可能会引入缓存、CDN 等基础服务来提供性能加速。

文章节选自《云原生应用架构实践》 网易云基础服务架构团队 著

网易云计算基础服务深度整合了 IaaS、PaaS 及容器技术，提供弹性计算、DevOps 工具链及微服务基础设施等服务，帮助企业解决 IT、架构及运维等问题，使企业更聚焦于业务，是新一代的云计算平台。点击可免费试用。