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

图片来自pixabay.com的hansbenn会员

本文从简单的单体应用架构说起,逐一介绍企业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. 阿里云:《数据库异地多活解决方案》

拍拍贷技术架构体系

拍拍贷公司成立于2007年6月,其技术体系最早基于微软.Net平台搭建,到了2016年,开始慢慢转向了Java平台,微服务开发也选择了当前业界流行的Spring Boot/Spring Cloud体系。在搭建微服务平台的过程中,拍拍贷基础架构团队并未全盘接纳Spring Cloud技术组件,更多是取其精华,兼并选择业界生产部署验证过成熟的组件。到现在2018年,微服务平台的搭建已过去快2年,整个技术体系已渐渐成型。

本文对当前拍拍贷的逻辑架构体系和微服务架构设计进行简单介绍,以供参考。

1. 逻辑架构体系

拍拍贷的逻辑架构体系如下图所示,

从上到下,分别有,

  • UI用户界面:提供Web应用和前端页面、移动应用、H5页面,以便于用户各个渠道的访问
  • Edge接入层:这一层承接外部所有用户的访问流量,负载均衡,并进行HTTPS的卸载,校验用户请求的合法性。同时,三大网关(API、移动、H5)还承接内部应用服务域名的调用访问流量。
  • Service服务层:主要的业务逻辑应用服务层
  • Platform平台层:包括各大Java服务中间件,微服务开发框架和平台,支撑整个业务服务应用的开发和运营。
  • Data Storage数据存储:数据存储层,主要包括三种:关系型数据库的MySql/MS Sql Server(目前逐渐从MS Sql Server往MySql迁移),缓存Redis,大数据的HBase。

2. 微服务架构设计

拍拍贷的微服务架构基于Spring Cloud,但很多组件选择了业界在生产环境已验证过、比较成熟的技术方案,比如配置中心、调用链监控、监控告警等。

整个微服务架构设计如下,

主要组件模块的功能如下,

  • 网关Zuul 1.0:提供服务路由、负载均衡、访问安全控制、熔断限流
  • 注册中心Eureka:服务注册和发现
  • 配置中心Ctrip Apollo:应用环境配置
  • 微服务Spring Boot:应用服务开发
  • 发布系统:通过网关实现应用服务的上下线、灰度发布、蓝绿发布
  • 调用链监控Dianping CAT:应用服务的监控埋点
  • 数据收集器Kafka:进行ELK的日志分析,收集运营Metrics到KairosDB
  • 运营指标KairosDB:存储相关的运营指标,包括业务、系统和运维指标,比如用户的访问量、消息的消费吞吐量、zabbix的运维监控数据等。
  • 运营看板Grafana:对接ELK/KairosDB/Zabbix,展现数据看板
  • 告警Zalando Zmon:健康和熔断告警

该图可以和Spring Cloud的微服务架构图相比较,可以看到拍拍贷在搭建微服务架构所做的改变,

  1. 添加发布系统,对接注册中心和网关,实现微服务实例的无缝上下线,实现灰度发布要求,为微服务的持续交付打下基础
  2. 添加ELK日志分析,完善监控告警,通过Grafana提供运营看板,确保微服务运营的快速、简单和稳定。在Spring Cloud技术体系中,其运营和监控是短板,ELK和Grafana作为业界流行的日志分析和运营看板组件,具有高可扩展性。
  3. 内部应用服务调用并未选择直连模式,而是通过服务域名走网关,简单可靠,其适合当前拍拍贷的业务运营需求。

3. 参考资料

  1. 拍拍贷的关于我们 https://www.ppdai.com/help/aboutus/

Spring Cloud微服务架构

Spring Cloud是一个面向分布式系统构建的技术体系,为开发人员提供了构建分布式系统所需的核心和外围组件,其基于Spring Framework和Spring Boot技术框架,使得能够“开箱即用”,快速搭建如下微服务架构所需的功能,

  • 服务注册和发现
  • 服务路由
  • 负载均衡
  • 访问安全控制
  • 应用配置
  • 熔断限流
  • 调用监控
  • 健康检查

一个由Spring Cloud所搭建的微服务架构体系如下图所示,

主要组件模块的功能如下,

  • 网关Zuul:提供服务路由、负载均衡、访问安全控制、熔断限流
  • 注册中心Eureka:服务注册和发现
  • 配置中心Config:应用环境配置
  • 微服务Spring Boot:应用服务开发
  • 流量监控Turbine:流量监控、熔断限流监控
  • 监控看板Spring Cloud Dashboard:应用健康状态、心跳检查、熔断限流看板
  • 调用链监控Sleuth:通过日志跟踪调用链
  • 日志分析ELK:日志分析
  • 告警:健康和熔断告警

图中Spring Cloud组件都用相应的图标标记,注意的是,日志分析和告警两个模块组件,Spring Cloud尚未涉及相关组件,需要对接第三方所提供的组件模块。对于这两个组件,图中参考了拍拍贷基础架构设计,分别选用了ELK和Zalando Zmon,详细请见下篇拍拍贷的技术架构体系设计

参考资料

  1. Spring by Pivotal https://spring.io/