大型网站架构的基本问题
从所有大型网站的共性来讲，大型网站架构的最终目的是可以通过简单地增减服务器来适应当前的用户数量。另外，网站系统的开发终归是量体裁衣的过程，每个网站系统根据不同的运营目的和规模会有不同的功能需求，而大型的网站系统，往往也会有庞大的功能集合。
因此，大型网站架构的基本问题主要有两个：
- 如何应对大量的用户操作；
- 如何规划庞大的功能集合。
业务架构面临的挑战
业务指的是需要处理的事务。笔者对于业务的理解，就是某个特定场景需要处理的需求，比如电商网站系统有电商业务（如订单管理、商品管理、商家管理和用户管理等），直播网站系统有直播业务（如直播间管理和直播审核流程等）。简单地说，业务就是网站系统的功能。
对于大型网站而言，庞大的功能群是不可避免的，毕竟功能是一个网站的运营资本。但是很多时候，正因为功能群的庞大，导致很难整理出清晰的需求列表和功能结构（没有设计出一个清晰的业务架构）。没有清晰的业务架构的网站系统如图2.1所示，在这种情况下，看起来是整理完了所有的功能，但是这种没有任何逻辑的列举方式往往会造成需求遗漏，导致项目实施过程中频繁变动需求，最后导致项目严重超支。
图2.1 没有清晰的业务架构的网站系统
业务架构是必要的，它能帮助我们顺着业务逻辑思考功能点是否完备，避免需求遗漏。除此之外，业务架构对后续的架构设计和迭代计划都有一定的指导意义。业务架构主要包括两部分，即功能模块结构和核心业务逻辑。
功能模块结构是业务架构的主要部分。这部分需要划分出功能模块（业务模块），规整混乱的功能点。除此之外，用户角色、展示端和平台等信息也需要在此体现。以一个视频网站的业务架构为例，其功能模块结构如图2.2所示。一般而言，图2.2也被称为业务架构图。
图2.2 功能模块结构（业务架构图）
图2.3 业务主逻辑
核心业务逻辑是对功能模块结构的补充。一般而言，针对每一个功能模块，都需要梳理其主要的业务逻辑。另外，如果功能模块之间存在关联的话，也最好梳理这部分的业务逻辑。例如，一个视频网站的业务主逻辑如图2.3所示。其中，椭圆形代表的是用户角色，矩形代表的是平台入口，圆形代表的是某个资源的抽象。另外，业务逻辑图不需要把所有功能都表达出来，只需要把主要的业务逻辑表达清楚即可。
完善的业务架构确实能让整个项目的开发过程更加顺畅。但是，无论在项目实施过程中还是在运营过程中，都会不可避免地产生很多新的想法，自然也会产生很多需求变更（有时候甚至会推翻之前设计的业务流程）。因此，在大型网站项目中，始终如一的业务架构是很难做到的。大型网站项目的需求变更是很难约束的，而我们能做的就是控制需求变更的实施节奏，避免由于来回改动一些小问题而影响整个项目的进度。
综上，业务架构主要有以下两个挑战：
- 设计清晰的业务架构，在大量需求中规整功能模块，指定功能边界，理清楚产品业务逻辑。一般来说，按照本小节提到的“业务架构图”和“业务主逻辑图”来做即可解决这个问题。
- 把控需求变更的实施节奏，避免由于来回改动一些小问题而影响整个项目的进度。
关于这个挑战，在下节“业务架构的基本思路”中会详细说明。
技术架构面临的挑战
技术架构指的是软件架构，是一个软件系统的骨架。技术架构的作用是规划软件结构并明确开发规则，是为了指导和约束整个开发过程而存在的，技术架构的好坏会直接影响软件质量。一个没经过技术架构设计的网站系统如图2.4所示。
图2.4 没经过技术架构设计的网站系统
图2.4看上去虽然有点结构感，但是这样的结构图对开发过程是没有指导意义的。它的问题在于：第一，业务功能是罗列的，没有划分功能模块或子系统；第二，忽略了太多技术细节。在这样的项目里，开发人员的编码自由度过大，开发人员会按照自己的喜好编码，随着功能的增多和开发人员的更替，网站系统的内部会变得非常混乱，从而导致在维护或者升级网站系统的时候举步维艰。
这些没经过技术架构设计或者技术架构做得不好的软件，笔者称它们为一次性软件，它们像一次性塑料袋一样基本不可再升级维护，使用起来也会存在各种问题。技术架构设计的作用除了能明确软件结构以外，还能让开发团队井然有序地协同工作，让网站系统维护和升级更容易一些。但是要做好一个大型网站的技术架构是困难的，主要有以下几个挑战：
- 清晰地描述系统逻辑，并具备适度的技术细节描述。
- 清晰地划分功能模块或子系统。
- 根据开发团队的水平制定开发规则。
业务架构和技术架构的相互成全
有人说，做项目就是不断妥协的过程。这可能是因为没做好业务架构，开发过程中无原则地增加或改动功能，时间节点一拖再拖，导致最后上线的网站变成一个什么都有但又哪里都有问题的怪物；也有可能是因为技术架构没做好，软件结构模糊，开发过程纪律松散，导致网站系统内部凌乱不堪，用户使用过程中发现一堆Bug。
除此之外，还可能是业务架构和技术架构没有相互成全。业务架构一般掌握在项目管理者手里，项目管理者往往是希望功能多而全，开发周期更短一些；而技术架构一般掌握在架构师手里，架构师往往希望软件质量过硬，开发周期再长一些。这么看来，业务架构和技术架构本身是存在矛盾点的，这个矛盾点在于成本（时间成本和人员成本等）。
偏倚业务架构的项目往往会造成工作量过大、工期过短的状况，导致每个开发人员都会不断冲破技术架构的既定规则，随心所欲地编写代码以求开发速度最快，最后交付的网站往往就像是一个山寨的电子产品，外表看上去还可以，一旦开始使用就会发现各种问题。这样的网站系统后续升级是困难的，很多时候只能重新再做一个。
偏倚技术架构的项目往往会制定严苛的开发规则并选用最前沿的技术，造成团队遵守规则和学习前沿技术的成本过高，很多工期都没有花在生产上，导致工期一拖再拖，最后的结果往往是成本严重超标，而且迫于成本的压力，最后交付的软件质量也一定与预期差距很大，反而弄巧成拙。
业务架构和技术架构的相互成全，其实是找到成本的平衡点。对于业务架构而言，适当地砍掉一些开发起来比较费劲的非主要功能是有必要的；对于技术架构而言，不能只追求软件质量，也应该考虑业务功能带来的工作量、开发团队的水平和前沿技术的风险等客观问题，适当降低标准。
本文给大家讲解的内容是大型网站架构面临的挑战：大型网站架构的基本问题
- 下篇文章给大家讲解的内容是大型网站架构面临的挑战：业务架构的基本思路
