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

今天主要学习的架构的演变历史和架构面临的一些挑战，详细内容如下：

1 什么是架构

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

1.1 单机架构

软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上。

优点：简单

问题： C10K problem，也即单机处理 10k 个并发连接的问题。随着 epoll、kqueue 等技术的不断发展，高性能网络编程逐渐回答了 C10K 问题。但在互联网飞速发展的今天，我们正陆续面临 C10M、C10B 等问题。也就是说，单体服务一定是有架构瓶颈的。

1.2 垂直应用|垂直切分

在单体架构基础上，进一步地，再把不同应用的代码从之前一个大的进程中拆分出来，就来到了垂直应用架构。按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配 。

这种经过垂直切分的架构，尝试解决了单机服务的水平扩容、运维停服问题。当然这里面很多细节还没有提及，比如，多个机器上部署的进程如何保证数据一致性。虽然它们解决了单机服务的两个最重要的问题，但也面临着很多挑战。

这其中，有两个问题使得我们不得不放弃单体和垂直应用架构： 随着业务场景越来越复杂，服务的职责也越来越多。学过面向对象程序设计的同学都知道单一职责的重要性，在软件架构里也是一样的。开发者不仅要关心 Web 后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD 很难分出精力专注于业务能力的开发。业务发展需要上线、变更，将会影响所有其他不涉及的场景。一旦出问题，影响面不可估量。既然可以根据应用把架构做垂直拆分，那是否可以根据模块/职责对架构进行水平拆分呢？

1.3 SOA架构

我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，以服务为一等公民，并为它们之间的通信定义标准，便得到了 SOA 架构。 这里有两个相对比较重要的概念：

1. 服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的 Passport 服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等
2. 通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作 为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化。

去中心化的方向，最终的形态就是微服务架构，

1. 不同模块的 RD 可以专心于自己的业务逻辑了，开发迭代效率得到显著提高
2. 各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高

2 企业级后端架构的挑战

• 基础设施层面

  • 物理资源是有限的

    • 机器
    • 带宽

  • 资源利用率受制于部署服务

• 用户层面

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