架构是啥？

官方说法：

架构，又称为软件架构。

• 是有关软件整体结构
• 用于指导软件系统各个方面的设计

通俗来说：

实现一个软件有很多种方法，架构在方法选择上起着至关重要的作用。

俺的拙见：

项目开发的文件夹怎么分。

单机架构

具体来看一个问题：

刘师傅要开一个蛋糕坊，需要解决以下问题：

• 1，怎么做蛋糕

自己做，独家秘方，品质有保障。

• 2，怎么卖蛋糕

小本生意，边做边卖，避免货物堆积。

蛋糕问题引申到软件系统，就是单机问题。把所有的软件功能都实现在一个进程里，并部署在一台服务器上。（单机架构）

这样做的优点：

简单得不能再简单。

问题：

由于所有得服务都部署在一个进程上，所以我们同一时间内只能给一名用户提供服务，也就是当有很多的顾客来购买蛋糕时，只能给一名顾客提供蛋糕。同时，如果做蛋糕的师傅生病或者店面需要装修等，就必须停止营业。

那么问题来了，怎么才能卖更多的蛋糕呢？

雇佣更多的蛋糕师傅。(也就是摇人。)

单体架构，垂直应用架构 | 垂直切分

单体架构：

对应到蛋糕问题，就是雇佣更多的师傅，每个师傅的业务可以做水平拓展。既可以做蛋糕，也可以卖蛋糕。（师傅：我谢谢你噢。）同时，引入大堂经理，实现客户分流。同时，为了更好地满足客户的需求，可以对师傅们做一个垂直切分，即将师傅们划分为戚风蛋糕师傅，肉松蛋糕师傅，慕斯蛋糕师傅等等。

这样做的好处是：

实现了蛋糕店的水平扩容，满足了客户的具体需求。并且运维不需要停服。

问题：

每个师傅的职责过多，开发（做蛋糕）的效率不高。某个师傅如果生病请假的话，影响范围广，爆炸半径大。

那么问题来了，如何提高做蛋糕的效率？

分工协作。

SOA架构、微服务架构|水平切分

SOA（Service-Oriented Architecture）：

• 1，将应用的不同功能单元抽象为服务；

• 2，定义服务间的通信标准。

微服务架构：SOA的去中心化演进方向。

用做蛋糕的例子来解释，就是在上一步的基础上把师傅们进一步划分，首先划分为售卖蛋糕的师傅和制作蛋糕的师傅，制作蛋糕的师傅又可以分为和面师傅，烘培师傅和雕花师傅等等。师傅们的任务和目的只有一个，就是为客户提供服务。

同时，人多了师傅们交流起来也比较困难。为了更好地方便师傅们沟通交流，还需定义一套服务间的通信标准，用于方便更好地维护蛋糕系统的稳定性。简单来说就是，和面师傅只管和面，烘培师傅只管烘培，雕花师傅只管整活，以此类推。

问题：

• 数据一致性：

装货台一共交付了多少蛋糕？卖蛋糕的师傅和做蛋糕的师傅怎么对账？

• 高可用：

这么多师傅，如何合作？面没和好，烘培师傅怎么烘培？整活师傅怎么整活？

• 治理：

烤箱坏了，怎么容灾？

• 解耦 vs 过微

还要不要把服务继续拆分？和面的要不要分成倒面粉的和加水的和开始和的？这样下去运维成本高了，值当么？

小结

架构演进的初衷：好比做蛋糕

• 需求量越来越大，终归需要增加人手。
• 越做越复杂，终归要分工合作。

架构的演进思路：就像切蛋糕，蛋糕越做越大，一口吃不下，终归要切分。

• 竖着切（垂直切分）

具备横向拓展的能力，一个扛不住就多个来扛。（扛不住我就摇人。）

• 横着切（水平切分）

随着层级越来越深，水平切分可以让每个模块的独立性越来越强，耦合性降低。（活太多干不过来我就分工合作。）

企业级后端架构解析

刘师傅蛋糕店经过 3 年的勃发展，积累了良好的口碑和用户基础，接下来，需要扩大规模开分店，那么问题来了：

• 店面怎么盘:

1，买房。2，租房。

• 师傅怎么招:

1，刘师傅全家出马。2，招培训班出身的。

• 是否继续坚持纯手工制作?

1，纯手工制作。2，工厂批量生产。

• 规模大了之后，工作重心应该是?

1，精进蛋糕制作收益。2，蛋糕店重点方向梳理 & 未来规划。

云计算

云计算的概念：通过软件实现全自动化的管理，提供计算资源的服务网络。

• 基础:

1，虚拟化技术 - 整租 vs 合租（开玩笑，谁买得起房。）

2，编排方案 - 业主 vs 租赁平台架构

• 架构：

1，laaS (Infrastructure as a Service)

买房子 vs 房屋租赁平台

2，PaaS (Platform as a Service)

清包 vs 全包

3，SaaS (Software as a Service)

从零培训 vs 雇佣培训过的师傅

4，FaaS (Function as a Service)

纯手工制作 vs 蛋糕机批量生产

云原生

云原生，是云原生（计算）的简称。

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

• 容器化
• 服务网格
• 微服务
• 不可变基础架构
• 声明式API

基于这些技术，开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制，服务可以轻松应对频繁和可预测的重大变更。

云原生主要涉及四个大方面:

弹性资源：

基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面kubernetes 技术已经成为了业界的标准。

微服务架构:

还记得前面我们聊到的微服务架构么? 没错，它也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以迅速发展;统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变的更容易。

DevOps：

设计->开发>测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致。

服务网格：

如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中RPC 中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能。