这是我参与「第三届青训营-后端场」笔记创作活动的第一篇笔记
本次课程的内容主要有四部分：
1，什么是架构
2，企业级后端架构剖析
3，企业级后端架构的挑战
4，后端架构实战
内容充实，老师全程用蛋糕店的例子来进行类比，很好地帮助了小白快速了解后端架构的知识。
1，什么是架构
1.1，架构介绍
百科上的详细解释为：
软件架构所指的就是说相应的系列性的抽象模式，可以为设计大型软件系统的各个方面提供相应的指导。从本质上来看，软件架构是属于一种系统草图。在软件架构所描述的对象就是直接的进行系统抽象组件构成。连接系统的各个组件之间就是做到把组件之间所存在的通讯比较明确与相对细致的实施描述。处于相应的系统实现环节，那么就会使得细化这些抽象组件成为现实的组件，比如可以是具体的某个类或者是对象。从面向对象领域进行分析，那么各个组件之前实施的连接实现往往是接口。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。
简而言之就是：
1.2 单机架构
C10K问题，即单机处理10k个并发连接的问题，随着 epoll、kqueue等技术的不断发展，高性能网络编程逐渐回答了C10K问题。但在互联网飞速发展的今天，我们正陆续面临C10M、C10B等问题。
运维需要停服即任何运维操作都需要停服，因为只有一个单体服务，有用户使用的时间点没有办法运维。单机服务的模式，除了简单之外没有任何优点。当今互联网时代，单机服务的形态一般只适合出现在预研或初创阶段，但凡业务有发展和迭代的诉求，就应该快速做架构迭代。
1.3 单体，垂直应用|垂直切分架构
按照这个思路: 我们把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。多个机器就好比把蛋糕切成几大块，负载均衡层负责引导用户去事先切好的几块蛋糕处在单体架构基础上，进一步地，再把不同应用的代码从之前一个大的进程中拆分出来，就来到了垂直应用架构。按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配。
这种经过垂直切分的架构，尝试解决了单机服务的水平扩容、运维停服问题。当然这里面很多细节还没有提及，比如，多个机器上部署的进程如何保证数据一致性。这其中，有两个问题使得我们不得不放弃单体和垂直应用架构: 随着业务场景越来越复杂，服务的职责也越来越多，开发者不仅要关心web后端业务逻辑，还要关心缓存，持久化存储，甚至和机器打交道。长此以往，RD很难分出精力专注业务能力的开发，业务发展需要上线变更，将会影响其他所有不涉及的场景。一旦出问题，影响面不可估量。
1.4 SOA，微服务|水平切分
按照这个思路，我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，以服务为一等公民，并为它们之间的通信定义标准，便得到了SOA架构,这里有两个相对比较重要的概念: 服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的Passport服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作。 为了服务之间再好的通信，有两个大的发展方向∶中心化和去中心化。因为中心化的方案形态较重，拓展性不佳，普及性不佳。而去中心化的方向，最终的形态就是微服务框架。
这下： 1.不同模块的RD可以专心于自己的业务逻辑了，开发迭代效率得到显著提高；
2.各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高。
1.5 小节
2，企业级后端架构剖析
2.1 云计算
下图是云计算各层内容。
虚拟化技术包括三个方面：硬件（虚拟机)、操作系统〔容器)、网络。具体如下：
CPU虚拟化：CPU的虚拟化技术是一种硬件方案，支持虚拟 技术的CPU带有特别优化过的指令集来控制虚拟过程，通过这些指令集，VMM会很容易提高性能。
服务器虚拟化：服务器虚拟化能够通过区分资源的优先次序，并随时随地将服务器资源分配给最需要它们的工作负载来简化管理和提高效率，从而减少为单个工作负载峰值而储备的资源。
存储虚拟化：虚拟存储设备需要通过大规模的raid子系统和多个I/O通道连接到服务器上，智能控制器提供LUN访问控制、缓存和其他如数据复制等管理功能。
网络虚拟化：网络虚拟化整合后的设备组成了一个逻辑单元，在网络中表现为一个网元节点，管理简单化、配置简单化、可跨设备链路聚合，极大简化网络架构，同时进一步增强冗余可靠性。
应用虚拟化：应用虚拟化通常包括两层含义，一是应用软件的虚拟化，一是桌面的虚拟化。
编排方案包括:虚拟机编排方案(OpenStack) 、容器编排方案(Kubernetes)
2.2 云原生
云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
云原生技术为组织（公司)在公有云、自由云、混台云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。它的代表技术有:
容器化
服务网格微服务
不可变基础架构
声明式API
基于这些技术，开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制，服务可以轻松应对频繁和可预测的重大变更。
云原生主要涉及四个大方面: 弹性资源:基于虚拟化容器以及灵话的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面，kubernetes技术已经称为了业界的标准。
微服务框架：依托于功能单元结构，使云服务具备了快速迭代的可能，业务得以迅速发展，统一的通信标准能够帮助越来越多的组件加入云服务的大家庭，同时使各组件之间的交互变得更容易。
DevOp5: 设计->开发->测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致。
服务网格：服务网格的重要进步就是将业务逻辑和网络通信治理解耦开来。业务不需要再关心异构系统中RPC中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能。
2.2.1 云原生之弹性计算资源
2.2.2 云原生之弹性存储资源
2.2.3 云原生之DevOps
注：DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。 它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 它的出现是由于行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
2.2.4 云原生之微服务架构
2.2.4 云原生之微服务网格
服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。
服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理组件组成。
管理组件被称为控制层或控制平面（control plane），负责与控制平面中的代理通信，下发策略和配置。
代理在服务网格中被称为数据层或数据平面（data plane），直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
3，企业级后端架构的挑战
现阶段存在的问题：
3.1 离在线资源并池
在线业务的密集请求呈现和时间相关的潮汐性，且是实时性的，离线业务具有非实时性，这样的特点让离在线资源并池成为可能。可以根据时间来对离在线业务进行资源分配，提高资源的利用率。
同一个机器可以采用容器，cgroup等技术对设备的资源（如CPU）做隔离实现离在线隔离。
3.2 自动扩缩容
利用在线业务的潮汐性，对在线资源池进行自动地扩容以降低业务成本。
根据不同的场景进行扩缩容设计，对于大多数微服务而言，CPU使用得更多，可以将CPU P50作为一个参考指标。
3.3 微服务亲合性部署
3.4 流量治理
3.5 CPU水位负载均衡
当不同得CPU水位出现不平衡时，即CPU使用情况存在很大差异，可以采用策略将各个容器得CPU使用率达到一个均衡。
4，后端架构实战
主要问题是解决CPU水位负载均衡如何实现：
1,需要哪些输入。
2,设计时需要考虑哪些关键点。
问题分析提炼如下：
4.1 解决方案--自适应静态权重
给每个机器设置一个调权代理，根据容器对资源的使用量来改变其权重以适应业务的需求。
由于该方案存在以上两个缺点，于是需要对方案进行演进改良。
4.2 解决方案--自适应静态权重Alpha
设置一个动态权重决策中心来进行资源的分配，根据容器的权重进行动态地调整，但是由纯分布式的部署变成决策中心去拉去对应服务的指标，以获取各容器运行的状态。
但是这个系统会出现过度的流量倾斜，仍需要改进。
4.3 解决方案--自适应静态权重Beta
根据RPC的指标避免极端情况的出现。
