架构的演进：
- 单体
垂直切分：
-
垂直应用（按照业务线垂直切分，每个业务为一个单体）
- 水平扩容，运维无须停服
- 每个业务负责的职责还是太多（其中可能有职责的重叠、重复造轮子），开发效率不高。爆炸半径大
水平切分：
-
SOA (Service Oriented Architecture)
- 将应用的不同功能单元抽象为服务
- 定义服务间通信标准
-
微服务（SOA的去中心化演进）
一个形象的例子：
水平切分服务带来了一系列问题：
- 数据一致性（一共交了多少货？）
- 高可用（如此多服务如何合作？）
- 治理（某工具坏了怎么办？）
- 解耦与过微之间的取舍（解耦造成的运维成本是否值得？）
企业级后端架构
云计算
云计算是通过软件自动化管理，提供计算资源的服务网络。如下：
- IaaS(Infra as a service)
- 类比租下店铺
- P(latform)aaS
- 类比装修里的清包 vs 全包
- S(oftware)aaS
- 类比用熟手师傅（instead of 从零培训）
- F(unction)aaS
- 类比机器批量生产（instead of 纯手工制作）
云原生（计算）的代表技术：
-
弹性资源：虚拟化容器
-
弹性计算资源：
服务资源调度，计算资源调度（在线时：热门榜；离线：热门榜更新），MQ（在线：削峰、解耦；离线：大数据分析）
-
弹性存储资源：
经典（对象/大数据），RDB，meta data，NoSQL
把存储资源也当作一种服务
-
-
微服务架构：业务解耦、统一通信标准
- 云原生场景下，微服务的交互逻辑不必在业务逻辑中实现，直接交给框架就好
-
服务网格service mesh：
微服务间通讯的中间层，高性能网络代理，将治理与业务解耦的组件。相比RPC/HTTP，实现了异构系统的治理统一化，提供复杂的治理能力
-
DevOps
贯穿 设计-->开发-->测试-->上线-->调优/重构 一整个开发周期
企业级后端架构面临的挑战
-
基础设施层面，物理资源（机器、带宽）有限，资源利用率受部署服务的限制。
-
用户层面，网络通信开销较大，且随着应用体量增大，网络抖动会导致运维成本提高。又，不同的机器处理能力不尽相同，所以异构环境下，不同的实例资源水位不均。
下面是一些解决方案
离在线资源并池
在线业务以I/O密集型为主，有潮汐性（流量集中在某些时段）、实时性；离线业务以计算密集型为主（e.g. 数据分析），是非实时性的。
并池中，根据在线业务的潮汐性，对池中资源进行调配。在线资源使用少的时候（流量低时），就把资源让出来给离线资源。这样可以降低物理资源成本，提供更多的弹性资源。
自动扩缩容
对资源池进一步优化，依据某些指标（如cpu的利用率）利用在线业务的潮汐性自动扩缩容。
微服务亲和性部署
把较为相关的服务的容器放在一台宿主机，如此一来，微服务间可直接（通过中间件和service mesh）实现共享内存通信，服务可用性也会提高。
流量治理
也是基于middleware & service mesh的。
CPU水位均衡
IaaS根据容器的宿主机提供资源探针，检测容器的CPU等资源使用情况，反馈给service mesh。service mesh支持带权重的load balance策略（权重存储在service registry）。
-
自适应静态权重
每一台宿主机分别收集物理资源信息，然后自己去registry调整容器的权重
- 优势是完全分布式，可用性高；微服务中间件无适配成本。缺点是无法回滚，运行时也做不到自适应
-
自适应动态权重
- 出了问题还可以马上切回静态权重
- 只检测物理资源的简单自适应可能造成流量的过度倾斜，需要处理，采取的方案之一是容器上报RPC指标
-
问题在于时序数据库压力较大，且动态权重决策中心职责愈发臃肿。解决方案：继续微服务化，引入MQ进行削峰，离在线链路区分……
-
