软件架构-架构师的视角

The Fenix Project

架构是一门权衡的艺术。在失败中演进，向死而生。

演进中的架构

架构不是被发明的，而是持续进化的结果。

单体系统时代

使用单台机器就能支撑的系统，易于开发，测试，部署和运维。

缺点是：

1. 其中一部分功能出现故障（内存泄露，线程爆炸等），都会引起整个系统问题。

2. 某个功能的升级和迭代期间，整个系统不可用。

SOA时代

SOA初步解决了分布式环境下出现的服务的注册，发现，隔离，治理等主要问题。

SOA最根本的目标是找到一种自上而下的软件研发的方法论，让企业可以跟着他的思路，一揽子解决到软件开发中的所有问题。但是其过于复杂的流程和理论，每个步骤都需要懂得复杂概念的专业人员参与，导致难以普及。

微服务时代

微服务是一种通过部署多个小型服务，来构建单一应用的架构风格。这种服务围绕着业务能力而非技术标准来构建。各个服务可以通过不同的编程语言，不同的存储技术，运行在不同的进程中。服务会采用轻量级的通讯和自动化部署，来实现通讯和运维。

微服务从2005年被提出，经过十年的积累和蜕变，在2014年才发扬光大。让其发扬光大的9个特征：

1. 围绕业务能力构建。不同的业务，划分不同的服务。

2. 分散治理。每个团队，只对自己的服务负责。

3. 通过服务来实现独立自治的组件。不是通过“类库”来提供组件。

4. 产品化思维。避免把软件研发当成是去完成某种功能，而把他当成一种持续改进，提升的过程。

5. 数据去中心化。每个服务都可以具有自己的数据库。

6. 轻量级通讯机制。不同于ESB，BPM，SOAP等复杂的通讯协议，提供一种简单的通讯方式，比如RESTFUL风格的通讯。

7. 容错性机制。软件架构不再虚幻的追求永远的稳定，而是接受总会出错的事实。可靠的系统完全可以由会出错的服务来组成，这是微服务最大的价值体现。

8. 演进式设计。承认服务会被淘汰废弃，当一个系统中出现了不可替代的服务，不会说明该服务有多重要，而是系统设计的脆弱的表现。

9. 基础设施自动化。服务的构建，发布，运维工作的自动化。

后微服务时代

也可以成为云原生时代。容器化技术的出现，让解决分布式问题的方法由应用层提升到基础设施层。

Kubernetes和Spring cloud提供的分布式问题的解决方案：

无服务时代

也可以成为无服务器架构。让开发者只需要纯粹的去关心业务。

1. 不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；

2. 不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成；

3. 不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的；

4. 也不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任。