互联网架构演变过程

互联网架构演变过程

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 高速缓存

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、websphereweblogic）。
（课题：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等手段，实现服务之间的权限认证。

和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层，硬件负载，财大气粗的不二选择
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垮掉的事故案例）

架构思想

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

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