一、什么是架构

1.1 架构，又称软件架构

是有关软件整体结构与组件的抽象描述
用于指导软件系统各个方面的设计

Q:定义还是太抽象，能不能再通俗一点?

实现一个软件有很多种方法，架构在方法选择上起着至关重要的指导作用

Q:架构的重要性?

地基没打好，大厦容易倒
地基坚实了，大厦才能盖得高
站在巨人肩膀上，才能看得远

1.2 问题

兰师傅蛋糕坊要开张了，亟须解决如下问题:

如何做蛋糕

独家秘方，还是亲自做比较好

如何卖蛋糕

刚开始客流量应该不大，边做边卖

看起来问题都解决了，开张!

1.3 单机

软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上

优点: 简单
问题: 运维需要停服
演进: 如何卖更多的蛋糕?多雇几个蛋糕师傅

我们直接跳过前后端分离的介绍，直接快进到后端架构的内容。

通过前面的课程，相信大家都已经很好的掌握了“如何将服务器放给用户”。是的，软件系统一定是要对外提供服务的，那单机架构也就是最基本的“架构”(虽然可能算不上)。
问题: C10K proolem,也习单机处理10k个并发连接的问题。随着epol、kqueue 等技术的不断发展，高性能网络编程逐渐回答了C10K问题。但在互联网飞速发展的今天，我们正陆续面临C10M、C0B等问题:也就是说，单体服务一定是有架构瓶颈的。
回到兰师得蛋糕店，仅靠兰师傅自己卖蛋糕，就算再怎么磨练手速，每天能卖出去的量也是有上限的。运维需要停服。任何运维操作都需要停服，因为只有一个单体服务，有用户使用的时间点没有办法运维。再看我们的蛋糕店，如果兰师傅去上厕所了......
单机服务的模式，除了简单之外没有任何优点。当今互联网时代，单机服务的形态一般只适合出现在预研或初创阶段，但凡业务有发展和迭代的诉求，就应该快速做架构迭代。

1.4 单体、垂直应用|垂直切分

单体架构:分布式部署
垂直应用架构:按应用垂直切分的

单体

优点: 水平扩容运维不需要停服

问题: 职责太多，开发效率不高爆炸半径大

演进:如何提高做蛋糕效率? 分工协作

按照这个思路: 我们把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。多个机器就好比把蛋糕切成几大块，负载均衡层负责引|导用户去事先切好的几块蛋糕处在单体架构基础上，进一步地，再把不同应用的代码从之前一一个大的进程中拆分出来，就来到了垂直应用架构。按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配
这种经过垂直切分的架构，尝试解决了单机服务的水平扩容、运维停服问题。当然这里面很多细节还没有提及，比如，多个机器上部署的进程如何保证数据一致性。这些我们后面会一并讨论虽然它们解决了单机服务的两个最重要的问题，但也面临着很多挑战。这其中，有两个问题使得我们不得不放弃单体和垂直应用架构: 随着业务场景越来越复杂，服务的职责也越来越多。学过面向对象程序设计的同学都知道单一职责的重要性，在软件架构里也是一样的。开发者不仅要关心Web后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD很难分出精力专注于业务能力的开发业务发展需要上线、变更，将会影响所有其他不涉及的场景。一旦出问题，影响面不可估量
既然可以根据应用把架构做垂直拆分，那是否可以根据模块/职责对架构进行水平拆分呢?

1.5 SOA、微服务|水平切分

SOA (Service- -Or iented Ar chitecture)

1.将应用的不同功能单元抽象为服务

2.定义服务之间的通信标准

微服务架构: SOA的去中心化演进方向

问题:

数据一致性

装货台共交付了多少蛋糕?

高可用

这么多师傅，如何合作?

治理

烤箱坏了，怎么容灾?

解耦vs过微

运维成本高了，值当么?

按照这个思路，我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，以服务为一等公民，并为它们之间的通信定义标准，便得到了SOA架构。

这里有两个相对比较重要的概念: 服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的Passport服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等。
通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作。
为了服务之间更好的通信，有两个大的发展方向:中心化和去中心化。因为中心化的方案形态较重，拓展性不佳，普及性不佳，我们跳过不讲，感兴趣的同学可以自己了解一下。而去中心化的方向，最终的形态就是微服务架构。
这下，

1.不同模块的RD可以专心于自己的业务逻辑了，开发迭代效率得到显著提高

2.各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高

最后，我们还需要回答垂直切分和水平切分所产生的一系列问题:由单机部署演进来的分布式架构，如何解决数据一致性？服务越来越多，依赖越来越复杂，如何做到高可用？一个团队甚至一个人可能同时管理多个微服务，如何运维微服务的目标是强化单一职责，控制爆炸半径，如何在解耦和”过微“之间取舍？

1.6 小结

架构的演进初衷:好比做蛋糕。
需求量越来越大，终归要增加人手
越做越复杂，终归要分工合作
架构的演进思路:就像切蛋糕。蛋糕越来越大，一口吃不下终归要切分
竖着切(垂直切分)
横着切(水平切分)

二、企业级后端架构剖析

2.1 背景

兰师傅蛋糕店经过3年的蓬勃发展，积累了良好的口碑和用户基础，接下来，需要扩大规模:

店面怎么盘:

师傅怎么招:

兰师傅全家出马
招培训班出身的

是否继续坚持纯手工制作?

规模大了之后，工作重心应该是?

精进蛋糕制作收益
蛋糕店重点方向梳理&未来规划

2.2 云计算

云计算:是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石。

基础:

虚拟化技术-整租vs合租
编排方案-业主vs租赁平台

架构:

laaS (Infrastructure as a Service)

买房子vs房屋租赁平台

PaaS (Platform as a Service)

清包vs全包

SaaS (Software as a Service)

从零培训VS雇佣培训过的师傅

FaaS (Function as a Service)

纯手工制作vs蛋糕机批量生产

虚拟化技术:硬件(虚拟机)、操作系统(容器)、网络
编排方案:虚拟机编排方案(OpenStack)、容器编排方案 (Kubernetes)

2.3 云原生

云原生技术为组织(公司)在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。

聊完云计算，有必要马上来看一下云原生。云原生，实际是云原生(计算)的简称，它是元计算发展到现在的一种形态。

云原生技术为组织(公司)在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。它的代表技术有:

容器化
服务网格
微服务
不可变基础架构
声明式API

基于这些技术，开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制，服务可以轻松应对频繁和可预测的重大变更。

云原生主要涉及四个大方面:
弹性资源:基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面，kubernetes 技术已经称为了业界的标准
微服务架构:还记得前面我们聊到的微服务架构么?没错，它也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以迅速发展;统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变的更容易
DevOps:设计->开发>测试- >交付->开发- >测试>交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致
服务网格:如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中RPC中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能

2.4 云原生之弹性计算资源

弹性计算资源类型:

服务资源调度

微服务:和面、雕花
大服务:烤箱

计算资源调度

在线:热销榜单
离线:热销榜单更新

消息队列

在线:削峰、解耦
离线:大数据分析

2.5 云原生之弹性存储资源

弹性存储资源类型:

经典

对象:宣传视频
大数据:用户消费记录

关系型数据库

收银记录

元数据

服务发现:蛋糕店通讯录

NoSQL

KV:来个xx蛋糕

总结:将存储资源当成服务一样

2.6 云原生之DevOps

DevOps是云原生时代软件交付的利器，贯穿整个软件开发周期。
结合自动化流程，提高软件开发、交付效率

2.7 云原生之微服务架构

通信标准:

HTTP (RESTful API)
RPC (Thrift, gRPC)

微服务中间件RPC vs HTTP:

性能
服务治理
协议可解释性

云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做

2.8 云原生之服务网格

服务网格(Service Mesh) :

微服务之间通讯的中间层
高性能网络代理
业务代码与治理解耦

相比较于RPC/HTTP 框架:

异构系统治理统一化
与业务进程解耦，生命周期易管理

2.9 云原生蛋糕店

企业级蛋糕店架构:

售卖
蛋糕制作(肉松、慕斯)
会员激励
满意度分析
研发新品

三、企业级后端架构的挑战

3.1 问题

挑战:

基础设施层面

物理资源是有限的

机器
带宽

资源利用率受制于部署服务

用户层面

网络通信开销较大
网络抖动导致运维成本提高
异构环境下，不同实例资源水位不均

3.2 离在线资源并池

核心收益:

降低物理资源成本
提供更多的弹性资源，增加收入
解决思路:离在线资源并池

在线业务的特点

IO密集型为主
潮汐性、实时性

离线业务的特点

计算密集型占多数
非实时性

3.3 自动扩缩容

核心收益:

降低业务成本

解决思路:

自动扩缩容

利用在线业务潮汐性自动扩缩容

3.4 微服务亲合性部署

核心收益:

降低业务成本
提高服务可用性

解决思路:微服务亲合性部署

将满足亲合性条件的容器调度到一台宿主机
微服务中间件与服务网格通过共享内存通信
服务网格控制面实施灵活、动态的流量调度

3.5 CPU水位负载均衡

核心收益:

打平异构环境算力差异
为自动扩缩容提供正向输入

解决思路: CPU 水位负载均衡

laaS

提供资源探针

服务网格

动态负载均衡

四、后端架构实战

4.1 问题背景

兰师傅蛋糕店也碰到了类似的问题:

不同师傅干活的效率差距较大
有些师傅希望「能者多劳多挣」在这个背景下，继续像之前一样为每个师傅分配完全相同的工作，会引起他们的不满。。。

回到03最后的挑战————CPU水位负载均衡，应该如何设计?

1.需要哪些输入?
2.设计时需要考虑哪些关键点?

4.2 问题提炼

输入:

服务网格数据面

支持带权重的负载均衡策略

注册中心存储了所有容器的权重信息

宿主机能提供

容器的资源使用情况
物理资源信息(如CPU型号)

关键点:

紧急回滚能力
大规模
极端场景

4.3 自适应静态权重

方案:

采集宿主机物理资源信息
调整容器注册的权重

优势:

复杂度低
完全分布式，可用性高
微服务中间件无适配成本

缺点:

无紧急回滚能力
缺乏运行时自适应能力

4.4 自适应动态权重Alpha

方案:

容器动态权重的自适应调整
服务网格的服务发现&流量调
度能力

演进方向:

解决无法紧急回滚的问题
运行时权重自适应

缺点:

过度流量倾斜可能会有异常情况

4.5 自适应动态权重Beta

方案:

服务网格.上报RPC指标

演进方向:

极端场景的处理成为可能

缺点:

时序数据库压力较大
动态权重决策中心职责越来越多，迭代->变更->风险

4.6 自适应动态权重Release

演进方向:

微服务化
引入消息队列削峰、解耦
离在线链路切分
梳理强弱依赖

解决在线分析引擎的数据一致性问题:一致性哈希

解决时序数据库压力:将其作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算

离线分析:使用消息队列解耦、削峰

离线回馈在线

架构初探：谁动了我的蛋糕｜ 青训营

一、什么是架构

1.1 架构，又称软件架构

Q:定义还是太抽象，能不能再通俗一点?

Q:架构的重要性?

1.2 问题

兰师傅蛋糕坊要开张了，亟须解决如下问题:

如何做蛋糕

如何卖蛋糕

1.3 单机

1.4 单体、垂直应用|垂直切分

1.5 SOA、微服务|水平切分

1.将应用的不同功能单元抽象为服务

2.定义服务 之间的通信标准

问题:

1.不同模块的RD可以专心于自己的业务逻辑了，开发迭代效率得到显著提高

2.各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高

1.6 小结

二、企业级后端架构剖析

2.1 背景

店面怎么盘:

师傅怎么招:

是否继续坚持纯手工制作?

规模大了之后，工作重心应该是?

2.2 云计算

基础:

架构:

2.3 云原生

2.4 云原生之弹性计算资源

服务资源调度

计算资源调度

消息队列

2.5 云原生之弹性存储资源

弹性存储资源类型:

经典

关系型数据库

元数据

NoSQL

总结:将存储资源当成服务一样

2.6 云原生之DevOps

2.7 云原生之微服务架构

通信标准:

微服务中间件RPC vs HTTP:

2.8 云原生之服务网格

服务网格(Service Mesh) :

相比较于RPC/HTTP 框架:

2.9 云原生蛋糕店

三、企业级后端架构的挑战

3.1 问题

基础设施层面

物理资源是有限的

资源利用率受制于部署服务

用户层面

3.2 离在线资源并池

核心收益:

在线业务的特点

离线业务的特点

3.3 自动扩缩容

核心收益:

解决思路:

3.4 微服务亲合性部署

核心收益:

解决思路:微服务亲合性部署

3.5 CPU水位负载均衡

核心收益:

解决思路: CPU 水位负载均衡

laaS

服务网格

四、后端架构实战

4.1 问题背景

兰师傅蛋糕店也碰到了类似的问题:

回到03最后的挑战————CPU水位负载均衡，应该如何设计?

4.2 问题提炼

输入:

服务网格数据面

注册中心存储了所有容器的权重信息

宿主机能提供

关键点:

4.3 自适应静态权重

方案:

架构初探：谁动了我的蛋糕｜青训营

2.定义服务之间的通信标准