什么是软件架构

架构（Architecture）这个词源于建筑行业，本意是“对建筑物或者其他结构化物体进行计划、设计和构建的过程及其产物”。它 同时也作为一门艺术，表现了各个文明的特色。

回到软件行业，软件架构（Software Architecture）是指描述一个软件系统的基础结构，以及如何创建构建这个结构的方式。它虽然源于建筑行业，但又有很多的不同，本文就软件架构的演进历史，以及推动它演进的一个关键因素进行简单的介绍。

推动架构演进的关键因素

功能性需求往往是构成一个软件十分核心的部分，很多架构师和开发者往往专注于这些功能的实现，而忽略了某些非功能性的需求。但这些非功能性需求却是决定产品架构的关键因素。回想一下我们做的一些软件功能，是不是通过一个单体应用也能实现？抑或是使用其它架构也能实现？那为什么这个软件是现在这样的架构呢？往往是因为性能、可用性、可靠性等非功能性的需求，推动我们做出了这样或那样的决策，最终才让我们的软件有了现在的架构。

既然非功能性需求是一个决定软件架构的关键因素，那它包含了哪些东西呢？根据 ISO/IEC 25010:2011标准中的衡量软件质量的八大特征中，除了“功能匹配度”以外的七个特征，均为非功能性方面的特征：

架构演进史

单体架构

单体架构在很多地方也被称作 Monolithic Application，也是借鉴了建筑行业的名词Monolithic Architecture，原意是描述通过一块巨大的石头进行挖凿雕刻之后做成的建筑。在软件行业引申为一个将用户界面、数据访问等功能糅合在一起的单个程序。

这里的描述其实并不十分符合单体架构定义，虽然单体架构容易导致“大杂烩”，但也不排除一个单体架构的程序能够保持很好的可维护性（良好的分层和模块化）。况且构成后续架构模式的最基础，也可以看做是一个一个独立运行在单个进程内的程序，这些程序也应当遵循一些基础的架构原则，比如经典的三层架构。

在很多情况下，一个单体架构的软件足以满足需求了。这个时候就应该避免过度设计，避免为了追求时髦而强行的进行微服务拆分。那么在哪些因素的影响下，我们会将单体架构拆分为微服务架构呢？

·       可维护性：随着业务的发展，软件的功能势必会越来越多，相应的研发团队也会越来越大。很多人在同一个应用中进行很多功能的研发，会带来可维护性的下降，包括在模块化、可测试性以及运维等方面的影响；

·       性能：一个单体软件中的不同功能，或多或少在性能和资源利用率上是有区别的。例如面向后台管理运营的功能，它往往性能要求不是非常高，并且有的操作十分的吃资源；主业务链路上的功能对并发度、吞吐量、响应时间等性能指标要求相对高很多。如果将这两类功能都放在一个单体应用中，在进行横向扩展时，并不能很好的资源的利用率和资源的隔离有很好的支持，并且也限制了对不同业务功能进行特定优化的可能性；

·       可靠性：这也是影响单体架构向微服务架构演进的一个因素。但它不是一个关键因素，毕竟部分单体架构的应用也可以通过集群部署的方式，来提高可靠性。

SOA

SOA （Service Oriented Architecture）定义了一组标准，这个标准包括了如何让软件的组件变得可重用，如何通过接口在组件之间进行交互等等。企业基于 SOA 可以更快更高效的适应市场的变化。

发展历史

1.    1994 年由 Gartner 提出（参考）；

2.    2006年成立OSOA联盟，推进相关的行业标准；

3.    2007年 OSOA 转变为制定行业标准的 Open CSA国际组织；

ESB

ESB (Enterprise Service Bus) 也是由 Gartner 的成员于2002 年提出的，核心思想是利用一个中心化组件来处理各个应用之间的交互集成。它建立在 SOA 之上，也是标准中的一部分。

微服务架构

微服务架构早在 2005 年就被以“Micro-Web-Services”这个名称出现在了某个会议上，而“microservices”这个正式的称谓则是在 2011 年被使用的。

微服务架构是将许多松耦合且可独立部署的小型服务组成一个满足业务诉求的软件。这些服务往往具有以下特点：

·       服务可以有各自不同的技术栈，同时也包括了各自独立的数据库和数据管理模型；

·       服务之间主要通过 API 和消息进行通信；

·       以业务能力（限界上下文）进行服务的组织。

等等，这个定义开起来似曾相识，让人想起来 UNIX风格的流水线：

·       每个命令都是单独的一个程序，运行在各自的进程中。它们可能由不同的语言编写，管理着同步的数据；

·       命令之间通过标准输入输出和流水线进行通信；

·       以最小原子的功能（KISS原则）进行命令的组织。

事实上，微服务架构的诞生也正是参考了 UNIX风格的流水线，所以微服务架构真正的历史，可能得再往前推几十年。

微服务 vs SOA

面向服务架构（SOA）和微服务架构是不是听起来十分相似，事实上它们也有着千丝万缕的关系。但是通过一个类比，咱们大概就能了解它们的本质区别。 SOA 就像是当前的 EJB，是由一系列大厂提出的严苛又封闭的标准，阳春白雪似的产物；而微服务就像是来自开源社区的 Spring，开放自由且充满活力。两种在可维护性上（实现&维护成本）存在着巨大的差异，最终 Spring 和微服务都打败了 EJB 和 SOA。

云原生

在我看来（仅代表本人观点），云原生并不算一个完整的架构代际（不像单体到 SOA、微服务这样的变化）。云计算为我们系统开发的底层（IaaS/PaaS/SaaS）带来了很大的变化，而推动这一变化最根本的原因是成本考量。为了更好的适应这些变化，我们需要在架构设计上进行更多的考量，以达到更优的性价比。当这种考量达到一个极致的时候，即架构 100% 基于云计算设计，便可称之为“云原生”。举个栗子，Snowflake就是一个典型的云原生架构，它从设计时就100% 基于 AWS 的各种云服务，能充分利用云计算带来的各种好处，极致的降本增效；而同时期的其他数仓产品，虽然也能上云，但是本质上只是在云上模拟了一套传统的 IDC 环境，用上了但又不够极致。

云计算也发展了这么多年，国内外也有大大小小的各种厂商，但各自都有着不同的产品和实现。当我们选中某一个云之后，因为各种各样的限制，往往很难再迁移/适配到另一个云。所以 CNCF（Cloud Native Computing Foundation） 应运而生，它围绕着云原生的方方面面进行标准化，考察并纳入符合标准的产品。基于 CNCF 这套标准架构设计的产品，理论上不仅做到了云原生，也可以迁移/适配多种云。

总结

了解了这么多种架构，最后总结下来就是一句话：没有最好的架构，只有最合适的架构。我们要综合考量业务上的各种需求，特别是非功能性的需求，选择出一个更合适的架构。一旦采用了某种架构之后，系统也不是一成不变的，只要业务在发展，我们就需要保持架构的活性，随时都可以进行调整，甚至推翻之前的架构决策。