互联网架构演进方向
目录
- 1 业务架构
-
- 1.1 单体模式
- 1.2 中台战略
-
- 1.2.1 概述
- 1.2.2 背景
- 1.2.3 案例
- 1.3 总结与思考
- 2 数据架构
-
- 2.1 单数据库
- 2.2 主从读写
- 2.3 分库分表
- 2.4 高速缓存
- 2.5 数据多样化
-
- 2.5.1 分布式文件
- 2.5.2 nosql
- 2.5.3 搜索引擎
- 2.5.4 架构特点
- 3、应用架构
-
- 3.1 单机调优
- 3.2 动静分离
- 3.3 分布式
- 3.4 微服务
- 4、部署架构
-
- 4.1 单机器
- 4.2 角色划分
- 4.3 应用集群
- 4.4 多层代理
- 4.5 异地访问
- 4.6 云平台
- 5 架构思想
1 业务架构
相关文章：
互联网架构演进之路：https://blog.csdn.net/ZGL_cyy/article/details/126330968
中台架构介绍和应用价值:https://blog.csdn.net/ZGL_cyy/article/details/126317750
软件架构思想和系统架构图：https://blog.csdn.net/ZGL_cyy/article/details/126414922
千万级订单生成的痛点与架构:https://blog.csdn.net/ZGL_cyy/article/details/125830853
搭建高可用系统架构与性能优化:https://blog.csdn.net/ZGL_cyy/article/details/123890315
DDD软件架构领域驱动设计: https://blog.csdn.net/ZGL_cyy/article/details/131335237
SOA系统架构的演变:https://blog.csdn.net/ZGL_cyy/article/details/104865807
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等各个业务线。
- 现有的业务模式、流程等根据市场及时调整，变化非常快。
- 新的业务线可以被快速实现，不需要再重复开发底层的中台业务，调取中台接口组装即可。
1.3 总结与思考
- 单体业务模式容易引发什么问题？
单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：
1.复杂性逐渐变高
比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。
2.技术债务逐渐上升
公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。
3.部署速度逐渐变慢
这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。
4.阻碍技术创新
比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。
5.无法按需伸缩
比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。
- 中台化的理念是什么？带来哪些挑战？
中台架构介绍和应用价值:https://blog.csdn.net/ZGL_cyy/article/details/126317750
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
2）特点
数据延迟：从主库到从库之间数据需要经过网络传输，不可避免的有延迟
开发层面：需要开发框架具备多数据源的支持，以及自动化的数据源切换
单库瓶颈：业务越来越多，表数量越来越多。出现单个库几百张表的现象
数据局限：依然无法解决单表大数据的问题，比如订单积累达到亿级，即使在从库，关联查询依然奇慢无比
2.3 分库分表
2004-2007，淘宝V2.1，分库。
1）方案
主从库的写入依然是有一个统一的主库入口。随着业务量的提升，继续细粒度化拆分
业务分库：订单库，产品库，活动库，会员库
横向分表：（拆记录）3个月内订单，半年内订单，更多订单
纵向分表：（拆字段）name、phone一张表，info、address一张表，俩表id一致
（课题：每天千万级订单的生成背后痛点及技术突破）
2）特点
分库：不同的数据库，所以无法使用数据库事务，而分布式事务的效果并不理想，多采用幂等和最终一致性方案。
（课题：多服务之间分布式事务的一站解决，业务幂等性技术架构体系）
分表：拆了再聚合是一对矛盾，例如按下单时间维度的分表，需要按用户排序统计变得异常困难。
中间件：Sharding-JDBC（课题：分库分表下每天亿级订单生成的痛点与架构），Mycat，Atlas
2.4 高速缓存
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 分布式
开始进行服务拆分了！
单纯的动静分离只解决了自己服务的项目结构，跨项目接口调用时，必须经过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等手段，实现服务之间的权限认证。
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层，硬件负载，财大气粗的不二选择
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，k8s，k3s（课题：运维篇 docker，k8s深入原理与应用）
云化：容器化解决了资源的快速伸缩，但仍需要企业自备大量机器资源。推动私有云到企业云进化
2）特点
资源预估：注意资源的回收，降低资源闲置和浪费，例如大促结束后要及时回收。
运维要求：需要运维层面的高度支撑，门槛比较高
预估风险：云瘫痪的故障造成的损失不可估量，（openstack垮掉的事故案例）
5 架构思想
任何体系的成型不是一蹴而就，随着访问量，数据量的增长，业务需求在推动技术架构的发展变革。
- 知行合一，做之前，先考虑意义
- 原生优于定制，约定大于配置
- 什么都是，最后会沦落到什么都不是
- 控制技术欲，不要瞎折腾
- 留下扩展，但不要想到100年后
- 没有最好的，只有最合适的
- 够用就好，玩的越花，风险越大
- 简约最美