中小企业web应用的架构演化

本文从简单的单体应用架构说起，逐一介绍企业web应用在其演化进程之路上的各种典型架构，并对于各个架构阶段所面临的挑战进行讨论，最后讨论中小企业应用的终极架构目标：同城主备、异地双活。

1. 单体应用架构

在企业的创世阶段，应用开发是一个从0到1的阶段，选择一个简单架构，不仅可以快速搭建起业务，验证业务模式的正确性，还可以方便业务的快速频繁迭代。因此，很多创业企业都是从单体应用架构开始，这个应用架构的典型特点是：单应用+单数据库。

其架构示意图如下，

虽然是简单架构，麻雀虽小但五脏俱全，在这个阶段，选择合适的前后端技术栈和web框架非常重要，尽量为未来发展创造条件。

1.1 面临的挑战

业务的快速变化，应用迭代频繁，这是初期企业应用面临最大的挑战，这个时期，数据模型的设计甚至比技术栈的选择更加困难。很多时候，一旦业务发展起来了，再想对历史数据推倒重来，会是非常困难的一件事情。

为了能够面对业务的快速迭代，数据模型和应用尽量小范围、内聚、低耦合，在应用内尽量实现无状态的数据流转（比如：数据的事务操作），为未来的调整扩展留出空间、做好打算。

2. 高可用、高可靠、高性能的集群架构

当公司的业务发展起来后，对应用高可用、高可靠、高性能的要求随之而来，于是每一个应用服务部署多个实例，将其挂载在SLB下，通过SLB实现流量的均衡负载，这种集群部署方式其架构简单、技术成熟，在中小企业应用中非常流行。

为了保证数据的安全，一般会搭建起数据库的主从架构，主库用于读写，从库用于读。

2.1 架构示意图

一个集群架构的示意图如下，

图中显示了数据库的主从架构，更多的数据库架构设计可以选择，比如主主、一主多从、双主多从等。

2.2 面临的挑战

集群架构简单，部署起来也不复杂，刚开始很容易形成怎么快怎么做的问题，随着部署的应用数增多，机器环境的管理、应用的灰度部署和快速回滚、问题的定位等等，都会让部署问题显得特别突出。

这个时候，Jenkins等持续集成和持续交付工具的使用，配与一套行之有效的上线规范，将有利于上述问题的解决。

3. 微服务化架构

当公司的业务规模发展壮大到一定程度，应用数达到成百上千时，整个系统的复杂度将成倍增长，如何管控系统的复杂度是需要解决的问题。

为了解决这个问题，各种业界基础架构组件涌现登场，这是其发挥神通广大的时候，这些基础技术组件若按其实现目的有如下三种归类，

1. 组件抽象（即各种中间件）：缓存、消息、数据库访问、网关、隔离熔断、日志
2. 系统的复杂度管理：配置、灰度发布、日志、监控、告警
3. 架构解耦：RPC服务组件（RPC框架、服务注册和发现等）

从技术角度，各种中间件的使用相对比较独立，一般在企业应用架构早期便可引入；而对于配置、日志、监控、告警等组件，则会按需引入，这些组件的尽早使用将大大加速系统的运维效率。

而对于RPC服务组件，这是微服务化架构的核心组件，其主要解决服务和服务之间调用的问题。在引入RPC之前，应用和应用之间的调用通过HTTP + 域名 + 网关访问，这种方式的调用有三个主要弊端，

• HTTP通过网关跳转，通信效率低
• 网关成为流量瓶颈
• 应用的上线和下线需要频繁通知网关

RPC服务组件解决了上述的弊端，服务和服务之间可以通过IP直连调用，大大提高了服务和服务之间的访问效率，各个服务的上下线可以通过注册和发现机制自动感知，这是微服务化架构所带来的最大的改变。为了对接内外服务调用，在流量层也需要添加一层内网网关，不仅可以实现服务的内外服务调用转换，还可以实现微服务集群的按应用、按环境隔离。

3.1 架构示意图

一个微服务架构的简要示意图如下，

注：上图勾勒了微服务架构所需的逻辑组件，图中并未画出内外服务的网络调用路径，但这也是搭建微服务架构特别需要关注的方面。

3.2 面临的挑战

为了解决系统的复杂度，引入大量中间件和RPC组件，引入的同时本身就加大了对系统的技术投入，用好、管理好这些基础组件需要较深的技术储备。

从另一个方面，各种基础组件的组合解决方案也层出不穷，花样繁多，这也考验着微服务架构的搭建好与坏。选择合适、成熟的解决方案，谨慎引入一个技术组件，对一个技术组件的考察，不仅考虑其开发使用、和整体架构的融合度，还要考虑其未来的升级，充分的考察和评审有助于搭建良好的微服务架构。

在数据库这一层，一旦某业务表的存储记录达到上亿级别，则需要考虑其分库分表的需求。

4. 多机房架构

当公司的业务规模持续发展，若经营盈利能力较好，业务模式上也有需求，就可以考虑多机房的投资建设。

从架构上有如下几种选择，

• 同城主备：在同一个城市，搭建主副双机房，主机房正常接流量，副机房则冷备；容灾时主副流量切换。
• 异地双活：在两个较远距离的城市，搭建双机房，两个机房都同时接流量；容灾时流量切换到可用机房。
• 两地三中心：在两个较远距离的城市，搭建三机房，其中异地两个机房同时接流量，另外一个机房冷备；容灾时随时启用备用机房，流量切换到可用机房。金融行业为了保证数据和业务安全，有两地三中心的架构需求。

多机房的建设一方面满足业务的需求，实现用户就近访问，提高访问效率；另一个方面实现容灾建设，保障了数据不丢失、服务不中断的容灾目标。

对于大多数中小企业应用来说，同城主备、异地双活为终极架构目标。

4.1 架构示意图 - 同城主备

一个同城主备的示意图如下，

4.2 架构示意图 - 异地双活

异地实现双活，在应用层、数据层可以有两种实现方案，

• 方案1：两地提供等同的应用服务；数据层根据机房位置，实现异地的数据库冷备。
• 方案2：应用层根据业务归类，实现异地的应用服务冷备；数据库表根据业务应用归类，实现异地互为冷备。

两种架构模式的示意图如下，

• 实现方案1
  

• 实现方案2
  

4.3 面临的挑战

多机房架构的挑战主要来自网络架构方面，即使多机房之间拉取了双专线，网络的长距离传输导致的延时（大于100毫秒），对于实现容灾时的网络流量及时切换，会是挑战不小的工作。

因此，在多机房建设的前期，需要对如下方面进行充分的调研，

1. 网络架构设计：机房双专线搭建、VPC网络搭建、运行环境搭建
2. 容灾的自动化切换：监控告警、容灾预案、自动化切换（接入层、应用层、数据层）
3. 面临数据时延性传输的挑战：数据库的DTS同步、应用对数据一致性的容错、避免跨机房的访问调用

5. 架构演化的简单对比

架构演化	企业发展阶段	基础设施投入	人员投入	技术架构
单体	初期	少	1-2人	简单
集群	中期	一般	2-5人	中等
微服务	中长期	高	5-10人	复杂
多机房	根据业务需求和经济能力	非常高	10+人	复杂

6. 小结

任何一个成长型企业，软件架构的演化都将经历一个从简单到复杂的进化过程，在不同的阶段有不同的功能职责要求，需要搭建起相应合适的应用架构，承载起企业的发展。

对于大多数中小企业应用来说，基本可以做到集群架构，但是在微服务架构上的搭建好坏，取决于团队的技术储备。受限于经济投入和应用场景，多机房的建设是需要仔细考量后再做定夺。

7. 参考资料

1. 阿里云：《数据库异地多活解决方案》