【深入代码系列】手牵手一起学架构演变

技术一直在变，从单体到微服务，我们要对宏观的变化做到心中有数，才不会被趋势所抛弃。

互联网架构演变过程

从业务，数据，应用，部署多维度了解架构变化.

1、业务架构

1.1 单体模式

早期系统多以单体业务为主，逐个业务线扩张。系统也多呈现为多个mvc独立运行状态。各自打各自的。

以电商为例，可能按B2B，B2C，C2C不断扩张，每个业务一套系统，每个系统一个维护团队。

1）方案

代理层设置不同的二级域名，如b2b.abc.com，b2c.abc.com，分发给不同的服务器

2）特点

粒度较粗：纯以业务为导向，往往形成业务团队各自为战，新业务线出现时疯狂扩张

重复开发：相同功能可能在不同业务的项目中被重复开发，比如短信发送、支付、财务统计

1.2 中台战略

1.2.1 概述

中台在2015由阿里提出，其实是阿里共享业务技术部的成型过程。

中台是一种企业架构而不是单纯的技术层面，目前几乎各大电商都进行着中台化的建设。

中台不是什么新奇东西，实际上是“共享“理念在业务、系统、组织架构上的一种落地与实施。

关键词：共享、节约成本、协作

1.2.2 背景

单体业务模式带来很多问题：

1）技术架构上：

有些相同功能，各个团队重复建设和维护带来的重复投资
业务系统间的集成和协作成本高昂
不利于基础性业务的沉淀和持续发展

2）组织架构上：

部门在单体模式下往往每个项目一个团队。团队跟随项目疯狂扩展，利用率低。

中台类比之下：

中台模式下，基础业务也下沉到技术部门，甚至通过技术反推业务正向发展。
下层业务，变化不大的业务持续沉淀，接口像滚雪球一样越来越完善
上层业务，跟业务模式和运营产品有关的系统变化迅速，对底层接口封装组合即可

从业务角度拆分架构，基础业务团队提供服务给聚合服务团队

数据，人员架构足够大，才能这么干。比如阿里

1.2.3 案例

以经典电商中台划分为例：

1）业务中台

业务中台基于公共服务的沉淀，需要积累一些基础的业务服务。

这些服务在 B2B，B2C 等系统中都会具备，是相同的。

商品中心：商品、类目、sku、spu
交易中心：订单、状态流转、条目、支付
营销中心：促销、优惠券、活动
会员中心：账户、基本信息、收发货地址、商铺商家信息
仓储中心：仓库、库存
物流中心：发货信息、自主物流或外部物流对接
…

2）技术中台

与业务无关的基础沉淀，技术类内容可以在各个团队之间共享。

基础架构：核心类库、公共框架、基础服务、服务治理框架
中间件：分布式缓存、分布式消息、数据存储（db，nosql）、分布式文件、分布式调度
自动化运维：监控中心、资源管理、配置中心、发布中心、日志平台
自动化测试：任务协同、基础测试、性能测试、接口测试、持续集成

（有的公司会抽取一个运维中台，将开发层和系统层的内容分开）

…

3）数据中台

数据中台不是数据平台，也不是数据仓库，这三者是有区别的。举个例子：数据平台可以理解为数据库，数据仓库类比为报表。

而数据中台更贴近上层业务，带着业务属性。同样以接口形式为其他上层各个业务线提供持续调用。

数据抽取：从db，nosql，日志等各个来源提供抽取接口
数据接口：为上层业务提供需要的定制化业务数据接口
数据分析：行业分析与决策、数据驱动运营
人工智能：用户画像、商品推荐
可视化：数据大屏、信息展示、活动报表等
…

4）服务接入层

即大中台，小前台的前台，电商中直面用户的B2B,B2C等各个业务线。

现有的业务模式、流程等根据市场及时调整，变化非常快。
新的业务线可以被快速实现，不需要再重复开发底层的中台业务，调取中台接口组装即可。

总结与思考

单体业务模式容易引发什么问题？

最大的问题应该就是成本了

中台化的理念是什么？带来哪些挑战？

最大的困境应该是在人！理念是好的，但是想要落地实践却不是那么容易的。很多事情并不是你想推动就能推动的，在具体的公司具体分析。

其次，要有钱！可以折腾。

2、数据架构

2.1 单数据库

早在2003-2004淘宝V1.0就使用mysql，V1.1换成oracle，直到2007数据库重新往mysql回迁。

这个阶段往往引发追逐商业大型db如oracle（淘宝v1.1 ， mysql→oracle）

1）方案

java web项目直接通过jdbc，连接单一的数据库，读写扎堆在一块，单库上的机器io及cpu性能很快达到上限

数据库：mysql、oracle、sqlserver、db2等（关联文章：mysql性能调优）
持久层框架：jdbc，hibernate，jpa，mybatis（关联文章：mybatis源码剖析）

2.2 主从读写

为了解决单数据库的问题，出现了主从模式，读写分离。减轻压力。

淘宝从oracle换回mysql的历程中实现了主从库部署与读写分离。

1）方案

java web应用层连接多个数据库，数据库之间形成主从关系，主库上写，从库上读。读写压力被分散

数据库集群：一主多从、双主单写（关联文章：mysql千亿级数量线上扩容实战）
应用层开发：多数据源支持，spring multi datasource
中间件：Sharding-JDBC（关联文章：分库分表下每天亿级订单生成的痛点与架构），Mycat，Atlas

2）特点

数据延迟：从主库到从库之间数据需要经过网络传输，不可避免的有延迟
开发层面：需要开发框架具备多数据源的支持，以及自动化的数据源切换
单库瓶颈：业务越来越多，表数量越来越多。出现单个库几百张表的现象
数据局限：依然无法解决单表大数据的问题，比如订单积累达到亿级，即使在从库，关联查询依然奇慢无比

主从模式虽然读写压力分散，但是写入的节点仍旧是单节点，高可用也是个问题。同时主从间的同步也是个问题。

主从和集群:主从可以理解为数据的备份，而集群数据实时同步且高可用。

2.3 分库分表

就算是主从,数据量大了单节点的写仍然有性能压力。所有又有了分库分表。

2004-2007，淘宝V2.1，分库。

1）方案

主从库的写入依然是有一个统一的主库入口。随着业务量的提升，继续细粒度化拆分

业务分库：订单库，产品库，活动库，会员库
横向分表：（拆记录）3个月内订单，半年内订单，更多订单
纵向分表：（拆字段）name、phone一张表，info、address一张表，俩表id一致（关联文章：每天千万级订单的生成背后痛点及技术突破）

2）特点

分库：不同的数据库，所以无法使用数据库事务，而分布式事务的效果并不理想，多采用幂等和最终一致性方案。（关联文章：多服务之间分布式事务的一站解决，业务幂等性技术架构体系）
分表：拆了再聚合是一对矛盾，例如按下单时间维度的分表，需要按用户排序统计变得异常困难。
中间件：Sharding-JDBC，Mycat，Atlas

引入一个技术手段解决一个问题会不可避免会引发新的问题，同时操作不同的数据库，多节点的分布式事务也是个挑战。

2.4 高速缓存

上面的数据库是在磁盘中的存储，IO终究是有瓶颈，所有又有了在内存中存储，即nosql。

nosql

2006-2007，淘宝V2.2架构，分布式缓存Tair引入。

1）方案

数据库往往是系统的瓶颈，根据数据的冷热划分，热点数据如类目、商品基础信息放在缓存中，其他数据延迟加载

ehcache：非分布式，简单，易维护，可用性一般
memcache：性能可靠，纯内存，客户端需要自己实现，无持久化
redis：性能可靠，纯内存，自带分片，集群，哨兵(主从故障转移)，支持持久化，几乎成为当前的标准方案（关联文章：MTD巨头高性能缓存代理方案实战，Twemproxy高阶使用）

2）特点

缓存策略：冷热数据的存放，缓存与db的边界需要架构师去把控，重度依赖可能引发问题（memcache造成db高压案例；redis短信平台故障案例）
缓存陷阱：击穿（单一 key过期），穿透（不存在的 key），雪崩（多个 key 同时过期）
数据一致性：缓存和 db 之间因为同一份数据保存了两份，自然带来了一致性问题（关联文章：redis高阶技术剖析）

同样，高速缓存又有新的挑战，内存中存储，机器故障数据怎么持久化？先更新缓存，还是数据库？缓存穿透，雪崩，等等。

2.5 数据多样化

数据除了结构化关系，非结构化对象，还有图片，文档，等等

一个网站中，数据库和缓存只是一种基本的存储手段，除了这些，随着网站架构的发展其他各种形式的存储结构相继涌现：

2006-2007，淘宝V2.2，分布式存储TFS，分布式缓存Tair，V3.0 加入 nosql Cassandra，搜索引擎升级

数据库全文检索→搜索引擎、本地上传+nfs→分布式文件系统的演进，方案后期均有深入讲解

2.5.1 分布式文件

商品图片，上传的文件等

hdfs：大数据下的分布式存储（关联文章：Apache Druid打造大数据实时监控系统，基于Flink的打车平台实时流数据分析）
fastdfs
cephFs（关联文章：无限容量云盘分布式存储技术方案ceph）

2.5.2 nosql

redis 经典缓存，上节已介绍
mongodb（关联文章：mongodb海量数据生产扩容实战）
hbase
tidb（关联文章：TiDB亿级订单数据亚秒响应查询方案）

2.5.3 搜索引擎

搜索引擎：lucene，solr，elasticsearch（关联文章：电商终极搜索ElasticStack）

2.5.4 架构特点

开发框架支持：存储的数据多样化，要求开发框架架构层面要提供多样化的支撑，并确保访问易用性
数据运维：多种数据服务器对运维的要求提升，机器的数据维护与灾备工作量加大数据安全：多种数据存储的权限，授权与访问隔离需要注意

总结与思考

常见的数据库有哪些？持久层框架呢？
什么是分库，什么是分表？分表有哪些分法？
缓存有哪些问题，各是什么样的场景？

3、应用架构

3.1 单机调优

早年间的项目大多采用mvc开发。

1）特点

每个项目成一个mvc结构，部署在应用服务器上（tomcat、jboss、websphere，weblogic）。（关联文章：tomcat源码剖析）

随着业务扩张，需求迭代，项目变得越来越大，一个war包动辄几百兆。

那时候崇尚调优，jvm单节点调优甚至接近于强迫症的地步。（关联文章：jvm性能调优）

3.2 动静分离

早年间的Apache+tomcat，后被nginx几乎一统江山。（前后端开发模式的演进：mvc页面嵌套→接口化）

1）方案

静态响应：tomcat对静态文件响应一般，提取静态文件，直接由nginx响应
动态代理：后端api通过代理转发给tomcat应用机器

2）特点

开发层面调整：项目结构要同步调整，由原来的一体化mvc转换为后端api+前端形式。
前后协调：前后端的分工变得更明确，互相并行开发，独立部署，但也带来了接口协调与约定等沟通问题
跨域问题：后段与前端如果域名不同，可能存在跨域问题（head头，jsonp等手段可以解决）。

3.3 分布式

单体拆分后服务之间的调用不在一个jvm中了，属于网络间的调用。就又有了一堆概念，熔断，限流，降级，等等。

单纯的动静分离只解决了自己服务的项目结构，跨项目接口调用时，必须经过rest请求，不利于服务之间的交互。

淘宝V3.0，HSF出现，服务化导向，架构师忙于SOA和系统关系的梳理。

1）方案

公共服务：重复开发的基础服务提取出来，形成服务中心，避免重复造轮子，降低成本，架构团队出现。
独立性：各自服务独立部署升级，粒度更细，低耦合，高内聚
SOA理念诞生：服务治理的范畴，重在服务之间的拆分与统一接口

2）技术手段

异步化：

rabbitmq （相关文章：滴滴打车超时架构设计）
rocketmq（相关文章：滴滴打车排队原理与剖析）
kafka （相关文章：海量订单数据同步）

Rpc：

dubbo （相关文章：dubbo核心源码剖析，zookeeper源码剖析）
Rpc框架（相关文章：Rpc核心源码与手写Rpc，netty通信与进阶）

3）特点

界限把控：服务的粒度、拆分和公共服务提炼需要架构师的全局把控。设计不好容易引发混乱
部署升级：服务数量增多，人工部署变的不现实，必须借助自动化运维（相关文章：高效运维篇，docker、k3s、jenkins、Apollo应用发布实战）服务
可用性：抽调的微服务因需要被多个上层业务共享，可用性等级变高，一旦down机就是灾难
熔断和限流：做好服务熔断和限流，提防服务单点瓶颈造成整个系统瘫痪。短信提醒失败不要影响下单。（相关文章：cloud alibaba，sentinel限流）

3.4 微服务

1）方案

微服务是基于SOA思想，将系统粒度进一步细化而诞生的一种手段

中台化得以实现，各个中心以及前端业务拆解为多个小的服务单元。

2）技术手段

微服务经历了从1.0（cloud）到2.0的演化（service mesh），目前企业中主流的解决方案依然是cloud全家桶springcloud （相关文章：springcloud微服务前沿技术栈，spring、springboot源码剖析）

3）特点服务拆分：粒度并非越小越好。太小会带来部署维护等一系列成本的上升。（相关文章：skywalking微服务监控）

接口约束：系统增多，各个服务接口的规范化日益重要，要求有统一的服务接口规范，推动企业消息总线的建设
权限约束：接口不是任意想调就可以调的，做好权限控制，借助oauth2等手段，实现服务之间的权限认证。

总结与思考

如何理解微服务与SOA，分布式的关系？

常用的分布式服务框架有哪些？

4、部署架构

4.1 单机器

小型网站，阿里云小项目还有人在用。

1）方案

单台机器的性能很快达到上限，就是所说的资源不足了

然后开始提升配置，推动高配机器的发展，成本高昂

2）特点部署简单：采用web包部署与发布，db等资源同台机器连接，简单易操作。（相关文章：tomcat源码剖析）

资源争夺：在业务发展的初始阶段尚可支撑，随着访问量的上升，单机性能很快会成为系统瓶颈。

4.2 角色划分

稍微大一点的系统，把数据库、缓存、消息等中间件剥离出去，单独机器来部署

1）方案

多台机器：tomcat与mysql各自独占机器资源
针对性扩容：tomcat应用机更注重cpu的运算和内存，mysql更注重io与磁盘性能，针对各自情况扩容（相关文章：架构设计基础设施保障）

2）特点

数据维护：可以抽出单独的dba来维护数据库服务器
数据安全：需要跨机器访问数据库，链接密码需要注意防范泄漏

4.3 应用集群

2004-2005，淘宝V2.0，EJB为核心。V2.1架构下，引入spring框架走向轻量化和集群

1）方案

apache：早期负载均衡方案，性能一般
nginx：7层代理，性能强悍，配置简洁，当前不二之选（相关文章：openresty日活亿级用户流量控制）
haproxy：性能同样可靠，可做7层或4层代理。
lvs：4层代理，性能最强，linux集成，配置麻烦（相关文章：lvs+keepalived高可用部署实战）
f5：4层，硬件负载，财大气粗的不二选择（银行:money_mouth_face: ）

深有体会，比如为了看个报表，大手一挥，几万块的大屏设备直接买了。

2）特点

session保持：集群环境下，用户登陆需要分布式session做支撑（相关文章：多维系统下单点登录的深入讲解）
分布式协同：分布式环境下对资源的加锁要超出线程锁的范畴，上升为分布式锁
调度问题：调度程序不能多台部署，容易跑重复，除非使用分布式调度，如elastic-job
机器状态管理：多台应用机的状态检测与替换需要做到及时性，一般niginx层做故障转移
服务升级：滚动升级成为可能，灰度发布（相关文章：不容忽视的灰度发布）日志管理：日志文件分散在各个机器，促进集中式日志平台的产生（相关文章：集中式日志平台的深入应用）

4.4 多层代理

1）方案

机器规模进一步加大，动静态均有多个nginx负载，入口统一交给lvs负载。多层代理形成。

2）特点

机房受限：lvs依然是单一节点，即使keepalived做到高可用，流量仍然需要在唯一入口进入。

4.5 异地访问

淘宝V2.1时代，使用自己的TaobaoCDN。

将相同的系统部署多份，分散到异地多个机房，或者电信、移动等多个网络中。不同地点，不同网络接入的用户，有了不同的访问入口和选择。

1）方案

dns轮询：通过配置多个ip将服务部署到多个机房，通过dns的策略轮询调用，可以实现机房层面的扩容
CDN：就近原则，使用户获得就近的机房访问相关资源，自己投资太大，购买他方需要付费。

2）特点

基本解决了机器部署的扩容问题，随着业务的发展，扩容与收缩变得困难，促进资源调度层面的技术发展。

4.6 云平台

针对中台化的建设及微服务数量的飙升，部署和运维支撑同步进行着变革。面临微服务的快速部署，资源的弹性伸缩等挑战，容器化与云被推进。

案例：成百上千的服务数量庞大、大促期间某些微服务的临时扩容。

1）方案

虚拟化：vm方案，Openstack，Vmware，VirtualBox
容器化：docker
编排：swarm，k3s，k8s（相关文章：运维篇 docker，k8s深入原理与应用）
云化：容器化解决了资源的快速伸缩，但仍需要企业自备大量机器资源。推动私有云到企业云进化

2）特点

资源预估：注意资源的回收，降低资源闲置和浪费，例如大促结束后要及时回收。
运维要求：需要运维层面的高度支撑，门槛比较高
预估风险：云瘫痪的故障造成的损失不可估量，（openstack垮掉的事故案例）

总结与思考

常见的代理服务器有哪些？各属于网络的哪一层？

docker的编排工具有哪些？

~~不想成为运维的开发不是一个好的架构师~~

架构思想

任何体系的成型不是一蹴而就，随着访问量，数据量的增长，业务需求在推动技术架构的发展变革。

知行合一，做之前，先考虑意义
原生优于定制，约定大于配置
什么都是，最后会沦落到什么都不是
控制技术欲，不要瞎折腾
留下扩展，但不要想到100年后
没有最好的，只有最合适的
够用就好，玩的越花，风险越大
简约最美

架构就是缺什么加什么，不是一蹴而就的，不可能是完美的，我们要做的是胸中有沟壑，眼里有山河，然后静待风雨来。