共计 6601 个字符，预计需要花费 17 分钟才能阅读完成。
互联网架构演变过程
能力指标
- 可能从多个维度明确互联网这些年的趋势（以电商淘宝为例）
- 可能对各个阶段的技术解决方案初步理解
- 架构师课程的缩影，可能理解到整个课程课题在架构体系中的地位
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
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 等伎俩，实现服务之间的权限认证。
总结与思考
- 如何了解微服务与 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 垮掉的事变案例）
总结与思考
- 常见的代理服务器有哪些？各属于网络的哪一层？
- docker 的编排工具有哪些？
架构思维
任何体系的成型不是欲速不达，随着访问量，数据量的增长，业务需要在推动技术架构的倒退改革。
- 知行合一，做之前，先思考意义
- 原生优于定制，约定大于配置
- 什么都是，最初会沦落到什么都不是
- 控制技术欲，不要瞎折腾
- 留下扩大，但不要想到 100 年后
- 没有最好的，只有最合适的
- 够用就好，玩的越花，危险越大
- 简洁最美
本文由传智教育博学谷 – 狂野架构师教研团队公布
转载请注明出处！
