课程目录
01.什么是架构
√：了解抽象定义、问题、演进、例子。
02.企业级后端架构解析
->对企业中（后端）架构的剖析，看架构在企业里是一个什么样的“玩法”。
03.企业级后端架构挑战
->企业面临的（后端）架构挑战是什么？工作中如何解决？
04.后端架构实战
->用一个例子说明：架构中一个问题的产生到解决，的实践过程。
02. 企业级后端架构剖析
2.2.3 企业级后端架构解析-云原生之DevOps
- 概念
- DevOps是云原生时代软件交付的利器，贯穿整个软件开发周期。
- 结合自动化流程，提高软件开发、交付效率。
- 概念图：
- 设计
-
- 容量
- 技术选型
- 服务化
- 同步/异步
- 观测性
-
- 容灾
- 兜底
- 降级
- 流控
- 隔离
-
开发
-
测试
- 1.单测
- 2.集成测试
- 上线
-
- 构建
-
- 部署
5.调优/重构
- 1.
- 性能瓶颈
- 运维黑洞
-
- 成本优化
- 体验提升
6.赋能or开源
2.2.4 企业级后端架构解析-云原生之微服务架构
- 层次图：
- 通信标准
- HTTP（RESTAful API）
- RPC（Thrift,gRPC）
- （在介绍架构演进的时候也提到：微服务是 从单机->单体->SOA微服务 这整个演进链中比较成熟的阶段。那么云原生里架构的微服务所呈现的价态大概是：
- 在SOA里已经强调过，各个服务之间都得有一个通信标准 来指定如何做通信。云原生里有2类比较公允的通信标准：1.HTTP【超文本传输协议】:比如很多服务会提供RESTful API的形式给别人调用自己的服务。2.RPC【远程过程调用】：像Thrift、gRPC等等，都是RPC层面的通信标准。
- 在云原生环境里，业务不用特别去关注“需要提供一个HTTP的接口来让别人调用我”。因为微服务有很多中间件，可以直接提供RPC或是HTTP的能力。
- 真正使用时如何选择呢？我们用时往往会有一个负载均衡层，相当于“大堂经理”的概念，能帮我们做统筹分流。均衡层下面提供的通讯协议都是HTTP协议，所以其实这些协议更多在端上，例如“手机端、小程序端”，HTTP对于端上服务的调用有比较友好的节能性、可理解性。再往下，提供API、API Gateway服务，再往后面做调用链的传递的时候，往往使用Thrift的协议。这就是我们在做微服务时如何在HTTP、RPC之间做选择。我们可以有以下几种考量：）
- 微服务中间件RPC vs HTTP：
- 性能（绝大部分RPC协议会有通信压缩，性能会比HTTP要好一些）
- 服务治理（对于很多RPC中间件，天生具备一些治理能力：eg.在调用下游时，超时该怎样去控制。类比到师傅：其中一个师傅遇到了问题，如何把他跳过去，请求到别的师傅帮我做这样的事。）
- 协议可解释性（RPC性能比较高的原因是它有很多压缩的方案。绝大多数HTTP协议的编写的格式，有比较好的可解释性。）
- 解释
- 云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做
- （一般API的服务往下，就会使用Thrift的协议 来提供比较好的通讯效率，同时也会自然使用“中间件”所提供的服务治理的能力。
- 比如有些RPC服务会使用Thrift协议的框架，会同时支持2种协议的传输，去做链的传递，最后到达我们RPC的服务。也就是说，它和API服务的区别就是它提供服务的接口使用的是RPC的协议。
- 业务就只用关注自己所实现的业务层的逻辑，而与网络相关的、与提供的协议、通讯相关的，全部交给中间件来做就好。比如如果使用的是“HTTP”的协议，就用HTTP的框架就好。如果是“RPC”的，就用RPC的就行。
- 比如我这个业务逻辑需要做关系型的存储，那么可以直接把对应的数据使用数据库，所提供的SDK 来去访问就可以了。比如我这个服务使用了缓存，去做高效的数据的查询，就可以直接使用缓存服务所提供的能力。如果说你这个缓存也需要做 数据的持久化，或去跟数据库有数据的同步的话，也可以使用消息队列，来处理数据库消息的变更，然后刷新你的缓存。）
2.2.5 企业级后端架构解析-云原生之服务网格
-
层次图：
-
服务网格（Service Mash）:
- 微服务之间通讯的中间层
- 高性能网络代理
- 业务代码与治理解耦 （容器可理解为虚拟化的机器。可以关注图里的数据流即可。服务网格也会有一个数据面，去和进程有紧密的联系。假设它们都在容器里面，它们会使用进程之间的通信方式来去做通讯的约定。）
- 相比于RPC/HTTP框架：
-
异构系统治理统一化
-
与业务进程解耦，生命周期易管理
2.0 企业级后端架构解析-云原生蛋糕店
-
层次图：
-
企业级蛋糕店架构：
- 售卖
- 蛋糕制作（肉松、慕斯）
- 会员激励
- 满意度分析
- 研发新品
