这是我参与「第五届青训营 」伴学笔记创作活动的第 七 天

• 架构是什么
• 企业级后端架构
• 企业级后端架构面临的挑战

架构是什么

定义：架构是有关软件整体与组件的抽象描述，用于指导软件系统各个方面的设计。

架构的重要性：

架构对于软件系统，正如基石对于摩天大楼，奠定下稳固的基石才能成就万丈高楼。架构也正如此，好的架构有如下的体现：

• 可靠性，系统不易崩溃，高可用，可容错
• 安全性，系统安全可靠，可规避不法侵入，信息泄露等等
• 可拓展性，系统能够在保证流量高峰期的合理性能，通过容器服务进行拓展
• 易维护性，系统能够正确记录服务日志以供调试排查，系统的部署简单便捷
• 可伸缩性，当系统引入新的组件或者技术时，不需要改动原先系统代码接入就可以使用。

架构的演进：

单机 -> 单体 -> 垂直应用 -> SOA -> 微服务

单机架构：系统所有功能集成在一个文件中，同时系统部署在一台服务器的一个进程中。

• 优点：架构简单，开发成本低，周期短，适用于微小项目
• 缺点：不易于协同开发，不易于拓展及维护，维护需要暂停服务；系统的鲁棒性极差

单体架构：由单机演进，将同一个系统部署在多台服务器上，由多个服务一起服务应用。

• 优点：具备水平拓展扩容能力，运维不再需要停服
• 缺点：后端进程职责过多，服务压力大；爆炸半径较大，进程中的任一部分出错，都可能会导致整个进程崩溃。

垂直应用架构：在单机架构的基础上，将系统拆分成互不干扰的多个小系统。小系统也使用单体架构的模式部署在多个服务器上。

• 优点：一定程度上减轻了后端进程压力，缩小了爆炸半径
• 缺点：只是将大服务拆成小服务，但是并没有解决单机架构的缺点

SOA（面向服务架构）：引入了分布式服务价格（RPC），应用系统根据功能单元拆分，不同功能的模块通过 RPC 进行调用。

• 优点：各模块职责更清晰，易于运维，服务爆炸半径可控
• 缺点：调用需要使用 RPC，接口开发工作量增加；服务器需求量增加（预算增加）；需要设计一套完备的 ESB（企业服务总线）解决方案

微服务架构：将系统服务完全独立出来，并将服务处抽取成一个个微服务。微服务遵循单一原则，分工明确，服务不重合。

• 优点：服务粒度细，有利于资源重复利用；提高系统可维护性；去中心化，服务采用RESTful等轻量化通信协议
• 缺点：微服务过多，服务治理成本高，不利于系统维护；开发成本巨大，技术要求高

tips：

架构演进主旋律：提高软件系统的可用性，满足迭代需求，提高迭代效率

架构演进主思路：

• 垂直切分——分布式
• 水平切分——分层/模块化

企业级后端架构

云计算

云计算基础：

• 虚拟化技术

  • 硬件层面（VM 虚拟机）- KVM/Xen/VMware
  • 操作系统层面（Container 容器）- LCX/Docker/Kata Container
  • 网络层面 - Linux Bridge/Open v Switch

• 编排方案

  • VM - OpenStack/VMWare Workstation
  • Container - Kubernetes/Docker Swarm

云计算架构：

• 云服务

  • IaaS - 云基础设施，对底层硬件资源池的抽象
  • PaaS - 基于资源池抽象，对上层提供的弹性资源平台
  • SaaS - 基于弹性资源平台构建的云服务
  • FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流

• 云部署模式（拓展）

  • 私有云 - 企业自用
  • 公有云 - AWS/Azure/Google Cloud/Huawei
  • 混合云

云原生

云原生，实际是云原生（计算）的简称，它是云计算发展到现在的一种形态。

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

• 弹性资源
• 微服务架构
• DevOps
• 服务网格

弹性资源:

基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为弹性计算资源和弹性存储资源两个方面。

弹性计算资源：

• 计算资源调度：在线计算(后端服务) / 离线计算(Map-Reduce/Spark/Flinnk)
• 消息队列：在线队列 / 离线队列

弹性存储资源：

• 经典存储：对象存储 / 大数据存储
• 关系型数据库：Oracle、MySQL
• 元数据：服务发现
• NoSQL：KV 存储(Redis) / 文档存储(Mongo)

微服务架构:

微服务架构下，服务之间的通讯标准基于 HTTP / PRC 协议，二者区别？

• 性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers
• 服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等
• 可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好

服务网格:

服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。

• 微服务之间通讯的中间层
• 一个高性能的传输层网络代理
• 将流量层面的逻辑与业务进程解耦

服务网格相较于 HTTP/RPC 协议：

• 实现了异构系统治理体验的统一化
• 服务网格的数据平面代理于业务进程采取进程间通信的模式，使得流量相关逻辑（包含治理）与业务进程解耦，生命周期更易于管理。

企业级后端架构面临的挑战

基础设施层面：

• 云计算如何就解决近乎无线的弹性资源，提高物理资源的价值转换率？
• 如何利用闲置的物理资源，提高资源利用率？

用户层面：

• 微服务之间的通信开销较大，如何控制通信成本呢？
• 如何解决微服务因网络抖动导致的运维成本呢？
• 如何屏蔽异构物理环境带来的差异呢？

应对策略：

• 离在线资源并池
• 微服务亲和性部署
• 流量治理
• 屏蔽异构环境算力差异

总结

架构选择得从服务需求出发。一寸长一寸强，但是对于大部分的系统，应该考虑如何把好钢用在刀刃上，尽最大的可能实现需求。

当然学习架构是每个开发者的必经之路。架构的设计第一要义就是结合需求，其次要做足业界调研，第三才是技术选型，最后是考虑异常情况（用户输入校验，容灾能力）。