这是我参与「第五届青训营」伴学笔记创作活动的第 3 天
零、序言
本文记录和整理了本人在字节青训营中学习的一些所得所想，用于本人回顾和梳理相关知识点，也欢迎大家参考，一同学习。如果发现有问题或者错误，可以在下方留言或者私信我（＾-＾）
围绕架构的定义和演进两部分内容展开，介绍了架构的演进变迁、企业级架构的形态、面临的挑战和解决方案。
一、课程重点
- 什么是架构：围绕架构的定义和演进两部分内容展开
- 企业级后端架构剖析：详细介绍企业级后端架构的形态
- 企业级后端架构的挑战：企业级架构都面临着哪些挑战，如何解决
- 后端架构实战：结合前三部分的知识点，以第三部分中的一个挑战为例，讲解如何做架构设计
二、什么是架构
架构，又称软件架构，是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。
2.1 单机架构
『单体意味着自包含』，所有功能均实现在一个进程中，并部署在一台机器上。实现简单，不会出现进程间通信IPC，但运维需要停服；承载能力有限，有性能瓶颈，会出现 C10K 问题（单机处理 10k 以上并发请求）。更适用于预研和初创阶段，后续需要快速架构迭代。
2.2 单体架构
在单机架构的基础上，将进程部署到多台机器上，引入负载均衡层。优点是具备水平扩容能力；运维不需要停服。但每个后端进程仍然承担全部功能职责；进程中一个很小的模块出现问题，都可能导致整个进程崩溃；多进程的数据一致性问题。
单体系统的不足，必须基于软件的性能需求超过了单机，软件的开发人员规模明显超过了“2 Pizza Team”范畴的前提下才有讨论的价值。
2.3 垂直应用架构
在单机架构基础上，将进程按照某种依据切分开。然后再按照单体模式的思路，部署在多个机器上。 一定程度上减少了后端进程职责；一定程度上缩小爆炸半径。但没有根本解决单体架构的后端问题。
2.4 SOA
SOA (Service Oriented Architecture)，将进程按照不同的功能单元抽象为『服务』。定义了服务之间的通信标准，保证各个服务之间通讯体验的一致性。在SOA 时代，有三种有代表性的架构模式：烟囱模式、微内核架构、事件驱动架构。
优点：各服务的职责更清晰；运维粒度减小到服务，爆炸半径可控。
缺点：ESB (企业服务总线) 往往需要一整套解决方案。
2.5 微服务
微服务 (Microservice) 由 Peter Rodgers 博士在 2005 年度的云计算博览会（Web Services Edge 2005）上首次使用。是SOA的去中心化演进方向。
在《Microservices: A Definition of This New Architectural Term》中首次给出了现代微服务的概念：“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。”。此外还专门申明了微服务不是什么——微服务不是 SOA 的变体或衍生品。
该文章中给出了微服务的九个核心特征：围绕业务能力构建、分散治理、通过服务来实现独立自治的组件、产品化思维、数据去中心化、容错性设计、演进式设计、基础设施自动化。
在微服务架构中，服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等这些问题，在微服务中不再会有统一的解决方案，每个部分都需要考虑和抉择。
三、企业级架构剖析
3.1 云计算
3.1.1 云计算基础
云计算是指通过软件自动化管理，提供计算资源的服务网格，主要涉及到两个技术，虚拟化技术和编排方案。
-
虚拟化技术：整租 vs 合租
- 硬件层面（VM 虚拟机）- KVM/Xen/VMware
- 操作系统层面（Container 容器）- LCX/Docker/Kata Container
- 网络层面 - Linux Bridge/Open v Switch
-
编排方案：业主 vs 租赁平台
- VM - OpenStack/VMWare Workstation
- Container - Kubernetes/Docker Swarm
3.2.2 云服务
-
IaaS（Infrastructure as a service – 基础设施即服务）：云基础设施，对底层硬件资源池的抽象、比如华为云、阿里云。
-
PaaS（Platform as a service – 平台即服务） ：基于资源池抽象，对上层提供的弹性资源平台，比如高德地图开放接口。
-
SaaS（Software as a Service – 软件即服务）：基于弹性资源平台构建的云服务，比如各种网盘。
-
FaaS (Function as a Service-功能即服务)：更轻量级的函数服务。比如：Amazon 的 AWS Lambda。
云部署模式
- 私有云 - 企业自用
- 公有云 - AWS/A
- zure/Google Cloud/Huawei
- 混合云
3.2 云原生
云原生，实际是云原生（计算）的简称，它是云计算发展到现在的一种形态。
云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。
它的代表技术：
- 弹性资源：虚拟化容器、快速扩缩容。
- 微服务架构：业务功能单元解耦，统一的通信标准。
- DevOps：敏捷开发、CI/CD，比如DevStream、github CI/CD。
- 服务网格：业务与治理解耦，异构系统的统一治理能力，比如 Istio。
3.2.1 弹性资源
基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为『弹性计算资源』和『弹性存储资源』。
弹性计算资源：
- 计算资源调度
- 在线计算 - 互联网后端服务
- 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk
- 消息队列
- 在线队列 - 削峰、解耦
- 离线队列 - 结合数据分析的一整套方案，如 ELK
弹性存储资源：
- 经典存储
- 对象存储 - 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
- 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
- 关系型数据库：
- TiDB，可以看一下PingCAP 黄东旭对的数据库发展新趋势分析。
- 元数据
- 服务发现 - Eureka、Consul 和 Nacos
- NoSQL
- KV 存储 - Redis
- 文档存储 - Mongo
3.2.2 微服务架构
微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。
- HTTP - H1/H2
- RPC - Apache Thrift/gRPC
如何在 HTTP 和 RPC 之间选择？
- 性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers。
- 服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等。
- 可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好。
3.2.3 DevOps
敏捷开发、CI/CD，比如DevStream、github CI/CD。
3.2.4 服务网格
服务网格是微服务之间通讯的中间层，通过一个高性能的4层网络代理，将流量层面的逻辑与业务进程解耦。服务网格相比较于 RPC/HTTP 框架：实现了异构系统治理体验的统一化；服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理。
没有什么是加一层代理解决不了的问题！
四、企业级后端架构的挑战
4.1 挑战
基础设施层面：
Q：我们总说，云是弹性的，也就是说，在用户的角度，云提供的资源是无限的。然而，云背后的物理资源是有限的。在企业级后端架构里，云如何解决近乎无限的弹性资源和有限的物理资源之间的矛盾？
Q：闲事的资源就这么空着呢？如何提高资源利用率，提高物理资源的价值转换率？
用户层面：
Q：上了云原生微服务后，服务之间的通信开销较大，应该如何做成本优化？
Q：微服务看起来没有那么美好，抖动导致的运维成本较高，如何解决？
Q：异构的物理环境应该对用户是透明的，如何屏蔽这些细节？
4.2 离在线资源并池
考虑到在线业务的潮汐性，物理资源的用量不是一成不变的。离在线资源并池可以提高物理资源利用率，提供更多的弹性资源。其实现思路为利用在线业务的潮汐性自动扩缩容。
扩缩容指标：扩缩容可以依据CPU、内存的利用率来衡量。依据资源IO扩缩容比较难以实现，QPS 指标对于不同的服务来说，很难统一量化。
4.3 微服务亲合性部署
Q：微服务之间的通信成本较高，是否可以形态上是微服务架构，通信上是单体架构。
亲合性部署，通过服务网格控制面实施灵活、动态的流量调度。通过将微服务调用形态与资源调度系统结合，将一些调用关系紧密、通信量大的服务部署在同一个机器上，并且使用 IPC 代替 RPC 的方式，降低网络通信带来的开销。
4.4 流量治理
Q：微服务之间的通信流量为什么需要治理？
微服务调用网络很复杂，流量治理可以提高微服务的容错性，提供容灾设计、进一步提高开发效率、发挥 DevOps 的能力。
Q：都有哪些常用的治理手段？
解决思路：基于微服务中间件&范围网格的流量治理。
- 熔断、重试，解决单次请求失败如何处理。
- 单元化，隔离化，避免一个服务失败，影响另一个服务。
- 复杂环境（功能、预览）的流量调度，快速验证新服务的有效性。
Q：微服务中心件和服务网格在其中扮演着怎样的角色？
4.5 屏蔽异构环境的算力差异
Q：基础设施层往往是个复杂的异构环境，比如，有些机器的 CPU 是英特尔的，而有些是 AMD 的。就算是同一个品牌，也可能是不同代际。如何将这些差异屏蔽掉，使用户尽可能不感知呢？
核心收益：打平异构环境算力差异；为自动扩缩容提供正向输入
解决思路： CPU 水位负载均衡，在IaaS 层面提供资源探针，返回宿主机的CPU性能指标，在服务网格层面提供动态负载均衡，最后达到容器层面的负载均衡。
Q：什么情况下，我们觉得，服务需要扩容了？异构环境会对这个评判标准产生怎样的影响？
五、后端架构实战
如何设计一个根据主机层面的资源信息，实时进行流量调度的系统，打平不同宿主机异构环境的算力差异。
输入
- 服务网格数据面
- 支持带权重的负载均衡策略
- 注册中心
- 存储了所有容器的权重信息
- 宿主机能提供的有
- 容器的资源使用情况
- 物理资源信息（如CPU型号）
关键点
- 紧急回滚能力
- 大规模
- 极端场景
待补充
