初探软件架构及其演进 | 青训营笔记

Dillonz
127 阅读9分钟

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

前言

本文介绍了软件架构及其演进史，对企业级后端架构进行剖析，对于企业级架构遇到的问题，我们如何去解决，让我们一起进入学习吧！

什么是架构

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

通俗来讲，软件架构就像建筑的地基一样，实现一个软件有很多种方法，架构在方法选择上起到重要作用。只有地基坚实了，大厦才能盖的高。

假如兰师傅蛋糕坊要开张，需解决如下问题：

  • 如何做蛋糕

独家秘方，自己亲自做

  • 如何卖蛋糕

边做边卖

单机架构

单机架构，就是把所有功能都实现在一个进程里，并部署在一台机器上。

这种架构的优点是，开发和部署起来十分简单，但它存在性能瓶颈（ The C10K problem）即单机处理10k并发问题，随着epoll、kqueue等技术的不断发展，它的性能已经无法满足大多数企业的需求。对于蛋糕店来讲，这意味着蛋糕店里只有兰师傅一个人工作，一个人再怎么努力，每天能卖出去的蛋糕量是有限的。 image.png

注意，运维是需要停服的，因为只有一个单体服务，有用户使用的时间点是没有办法运维的？即如果兰师傅去上厕所了，蛋糕店怎么运作，如何卖更多蛋糕？

解决方案：

通过多雇几个蛋糕师傅（单体架构和垂直应用架构）解决此类问题。

单体架构和垂直应用架构

通过把单体架构通过分布式部署来对服务进行扩容。即对于蛋糕店来说，就是招了多个师傅去做相同的工作，招的师傅越多，卖的蛋糕数量就越多。。

image.png

在单体架构的基础上 ，进一步地，再把不同应用的代码从之前一个的进程中拆分出来，就形成了垂直应用架构，按应用拆分进程，就好比如把做戚风蛋糕、肉松、慕斯等操作进行分类，分发到各个师傅手上。

image.png

值得一提的是，无论是单体架构还是垂直应用架构，都需要一个中心化的负载均衡层引导用户使用需要的服务。对于蛋糕店来讲，就是类似大堂经理的职责。

单体架构和垂直应用架构都尝试解决了单机服务的停服问题，且这种架构还支持水平扩容，只需要简单增加服务数量，就可以轻松服务更多用户。但是这种架构的缺点是，随着业务场景越来越复杂，服务的职责也越多（例如肉松蛋糕师傅虽然只做肉松蛋糕，但是他仍然需要负责发面，装饰雕花，售卖等职责，其他师傅也需要做同样的事）。学过面向对象程序设计的同学都知道单一职责的重要性，在软件架构里也是一样的。开发者不仅要关心Web后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。每个服务虽然各自独立，但分配的职责太多这导致每个服务开发效率急剧降低，相似代码增多，且爆炸半径巨大（如蛋糕店的某个蛋糕师傅无法正常制作，那我们就需要排查这个师傅做过的所有操作中那步操作有问题）。

那么如何提高做蛋糕的效率？

解决方案：

即我们引入分工协作的方式来提高做蛋糕的效率，这就是 SOA 和 微服务。

SOA 和微服务架构

SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。

SOA 以水平切分的思想，通过将一个应用之间有关联和无关联的功能都切分成一个个单独运行的服务，并通过某种通信标准（例如 HTTP, RPC）交换数据，最终构成一个完整的服务整体。以拿蛋糕店举例，此时大堂经理通过和戚风蛋糕、肉松蛋糕、慕斯蛋糕等各个售卖点进行沟通，然后售卖点联系和面师傅、其他杂活师傅、烤箱师傅进行蛋糕制作，最后把蛋糕交付给客户。

image.png

为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化。 因为中心化的方案形态较重，拓展性不佳，普及性不佳，所以略过不讲。感兴趣的可以自己上网了解下， 而SAO去中心化的最终形态就是微服务架构。即把蛋糕店的职能被进一步拆分，每个单独职能都可和其他职能进行必要的沟通交流。

image.png

SOA 和微服务架构通过引入分工协作有效的提高了开发迭代效率，不同模块的RD可以专心于自己的业务逻辑；各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高。

当然，这也带来了更多问题：分布式架构带来的数据一致性问题；服务越多，依赖越复杂，如何做到高可用；一个人或者团队管理多个微服务，如何运维；微服务的目标是强化单一职责，控制爆炸半径，如何在解耦和过微之间取舍。这些问题都是企业级后端架构常见的问题。

企业级后端架构剖析

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

  • 店面怎么盘
    • 买
    • 租
  • 师傅怎么招
    • 自己出马
    • 招培训班出身的
  • 是否继续坚持纯手工制作？
  • 规模大了之后，工作重心应该是？
    • 精进蛋糕制作收益
    • 蛋糕店重点方向梳理&未来规划

云计算

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

云计算的基础是虚拟化技术（例如 KVM, Hyper-V，可以简单理解为虚拟机服务）和编排方案（例如 Kubernetes, OpenStack，将不同的虚拟机或容器以某种方式组合在一起，动态使用）。

云计算的架构由 IaaS（Infrastructure as a Service，基础设施即服务，例如腾讯云，AWS），PaaS（Platform as a Service，平台即服务，例如 Heroku，Netlify），SaaS（Software as a Service，软件即服务，例如 Microsoft 365，Adobe Creative Cloud），FaaS（Function as a Service，功能即服务，例如云函数，AWS Lambda 等） 等共同组成。

云原生

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

云原生之弹性资源

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

弹性计算资源

  • 计算资源调度
    • 在线计算-互联网后盾服务
    • 离线计算-大数据分析。Map-Reduce/Spark/Flinnk
  • 服务资源调度
  • 消息队列
    • 在线队列-削峰、解耦
    • 离线队列-结合数据分析的一整套方案，如ELK

弹性存储资源

  • 经典存储
    • 对象存储-视频、图片等、结合CDN等技术，可以为应用提供丰富的多媒体能力
    • 大数据存储-应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
  • 关系型数据库
  • 元数据
  • NoSQL
    • KV存储-Redis
    • 文档存储-Mongo

在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。

云原生之DevOps

DevOps 是云原生时代软件交付的利器，贯穿整个软件开发周期。结合自动化流程，提高软件开发，交付效率。常见的 DevOps 有敏捷开发，CI/CD 等。

image.png

云原生之微服务架构

云原生场景下，微服务不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做（如RPC，HTTP 等协议进行通信）。

image.png

云原生之服务网格

服务网格（Service Mesh）：

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

相较于PRC/HTTP框架：

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

image.png

企业级后端架构的挑战

问题：

基础设施层面：

  • 物理资源有限
    • 机器
    • 带宽
  • 资源利用率受制于部署服务

用户层面：

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

解决方案：

  • 离在线资源并池
  • 自动扩缩容
  • 微服务亲和性部署
  • 流量治理
  • CPU 水位负载均衡

后端架构实战

问题：

如何设计一个根据主机层面的资源信息，实时进行流量调度的系统，打平不同宿主机异构环境的算力差异。

输入：

  • 服务网格数据面
    • 支出带权重的负载均衡策略
  • 注册中心存储量所有容器的权重信息
  • 宿主机能提供
    • 容器的资源使用情况
    • 物理资源信息（如CPU型号） 关键点：
  • 紧急回滚能力
  • 大规模
  • 极端场景

image.png

引用

  • 字节内部课：架构初探 - 谁动了我的蛋糕
avatar
文章
阅读
粉丝