优百信息

【引言】

“架构”一词由来已久，最早用(yòng)于建筑學(xué)，原本指的是建筑物(wù)设计和建造的艺术。

在软件工程领域，软件架构也不是一个新(xīn)名词，所谓“架构”，就是指软件系统的整體(tǐ)结构，包括软件的各个子模块以及模块之间关系的體(tǐ)现。软件架构和软件设计在概念上是统一的，二者没有(yǒu)區(qū)别，它们的产出都包括系统架构图、概要设计、详细设计等等，这些都體(tǐ)现出了架构师对于业務(wù)功能(néng)的理(lǐ)解和抽象，以及相对应的软件系统的设计。类似建筑设计师设计使用(yòng)的图纸一样，架构图以及相关的文(wén)档实际上包含了软件系统的所有(yǒu)底层设计细节，这些细节信息共同支撑了顶层的设计实现，底层与顶层的设计都體(tǐ)现出软件系统的标准，发展方向和指导思想。

现实中我们经常会遇到為(wèi)了加快发布速度而被匆忙搭建起来的系统。这类系统通常没有(yǒu)经过良好的设计便匆匆开工。初期，团队的开发效率都很(hěn)高，然而随着产品的迭代，项目规模的扩大，不可(kě)避免的出现代码随处拷贝，复杂性扩散，代码质量下降，业務(wù)模块相互耦合等情况，工程师的开发效率呈直線(xiàn)下降的趋势，最终造成产品维护困难，甚至不可(kě)维护，投入成本成指数增長(cháng)但是产品质量却在下降。问题所在就是大家对架构设计和代码质量的可(kě)维护性存在着長(cháng)期、持续的忽视。

那么，实现一个好的系统架构的目标是什么呢(ne)？架构师们所做的各种决策，最终的目标就是為(wèi)了能(néng)够达到，用(yòng)最少的人力成本来满足构建和维护该系统的需求。判断一个软件系统架构优劣的标准很(hěn)简单，就用(yòng)它满足客户需求所需要的成本来判别。如果该系统成本很(hěn)低，并且在整个后续的迭代过程中，包括需求的变更和维护等都维持一个相对低的成本，那么就可(kě)以说这种软件系统架构是一个优秀的软件架构设计。

【演化历程】

一般的互联网或者企业级的产品应用(yòng)都是通过浏览器的web系统提供一组业務(wù)服務(wù)。

这类系统包括提供给用(yòng)户可(kě)操作的、运行于浏览器环境中的具有(yǒu)良好UI样式的业務(wù)逻辑展示单元和输入单元，以及包括运行于服務(wù)器环境中、用(yòng)各种面向对象语言构建的业務(wù)逻辑处理(lǐ)单元，和用(yòng)于存储业務(wù)数据的各种关系型和非关系型数据存储单元。

常见互联网架构                                                                   服務(wù)化互联网架构

随着时代的发展，软件系统架构设计的表现和相关的部署风格等一直在不断演进。从最初的的单體(tǐ)架构逐步进化到分(fēn)布式架构，目前分(fēn)布式架构在各个软件系统中普遍存在，应用(yòng)很(hěn)广泛。

单體(tǐ)架构指的是整个系统的所有(yǒu)功能(néng)单元，完全部署到同一个服務(wù)器的同一个进程中。而分(fēn)布式架构指的是功能(néng)单元分(fēn)散到不同服務(wù)器的不同进程中，然后由多(duō)个进程共同来提供一组业務(wù)逻辑，又(yòu)可(kě)细分(fēn)為(wèi)：面向服務(wù)架构(SOA)、分(fēn)布式服務(wù)架构、微服務(wù)架构。其中，面向服務(wù)架构关注的是服務(wù)，即服務(wù)是最基本的业務(wù)功能(néng)单元，通过将业務(wù)系统服務(wù)化，可(kě)以将不同的业務(wù)模块解耦合，各种异构的系统之间可(kě)以实现服務(wù)的消费，资源的共享；而微服務(wù)架构则是相比SOA更细致化的架构服務(wù)，它是以实现一组微服務(wù)的方式来开发一个独立的应用(yòng)系统的方法，其中，每个小(xiǎo)微服務(wù)都运行在自己的进程中，通过全自动化的部署方式来进行独立部署，实现各个异构的系统之间服務(wù)的消费和资源的共享。微服務(wù)是将 SOA 中原本可(kě)能(néng)聚合在同一个系统内的多(duō)个服務(wù)组件拆分(fēn)到各自独立的系统进程中，提供组件化的和可(kě)高度复用(yòng)的微服務(wù)。微服務(wù)的优势在于：彻底的组件化，将一个服務(wù)中设计的多(duō)个微服務(wù)进行解耦合，各个微服務(wù)系统的规模小(xiǎo)很(hěn)多(duō)；每个微服務(wù)对应一个独立的开发和维护团队，有(yǒu)利于团队间独立的开发；各个微服務(wù)系统相互独立，仅通过rpc进行遠(yuǎn)程调用(yòng)，可(kě)以实现独立部署和扩展，当系统性能(néng)出现瓶颈时，可(kě)以做到细颗粒度的有(yǒu)针对性的扩展和优化单个或者部分(fēn)的微服務(wù)系统。同样的，微服務(wù)架构的缺点也很(hěn)明显，微服務(wù)的拆分(fēn)提高了对部署和测试的要求，部署和测试的复杂性大大提升；系统问题的排查、数据的一致性、系统监控等都会因為(wèi)微服務(wù)的拆分(fēn)而增加难度等等。总的来说，我们需要根据项目的应用(yòng)环境，功能(néng)的复杂程度，团队结构的划分(fēn)等来合理(lǐ)的采用(yòng)不同的系统架构，而不是一味的使用(yòng)最新(xīn)或者最流行的系统架构。

【应用(yòng)标准】

软件架构的实质就是规划如何将系统切分(fēn)成组件，并整理(lǐ)好组件之间的排列关系，以及组件之间相互关联的方法。而设计系统架构的目的也是為(wèi)了在工作中更好的对这些组件进行独立的开发、部署、运行以及维护。

要想构建一个好的软件系统，良好的架构设计和优秀的代码质量是必不可(kě)少的，按照SOLID原则来进行设计便可(kě)以帮助我们来解决这些问题。SOLID原则指导我们怎样去组织和封装提供服務(wù)的代码，使得软件易于维护、代码易于理(lǐ)解、组件易于复用(yòng)。

SOLID原则包含如下：单一职责原则(SRP)，开闭原则(OCP),里氏替换原则(LSP),接口隔离原则(ISP),依赖反转原则(DIP)。

单一职责原则：任何一个软件模块都应该只对某一类行為(wèi)者负责。具體(tǐ)来讲，就是把不同的业務(wù)功能(néng)进行隔离，确保一个业務(wù)系统的改动不会引起相关业務(wù)系统的改变和重新(xīn)部署。

开闭原则：计算机软件系统应该易于扩展，但同时抗拒修改。意思是说一个设计良好的软件系统应该可(kě)以在不修改源代码的基础上就可(kě)以扩展功能(néng)。

里氏替换原则：如果当衍生类可(kě)以替换父类时，而软件的功能(néng)不受影响，那么子类对于父类具有(yǒu)可(kě)替换性。一旦违背了里氏替换原则，我们為(wèi)此就不得不引入大量的冗余且复杂的功能(néng)代码。

接口隔离原则：任何层次的软件设计都要保持简洁，确保不会依赖不需要的东西，否则就会带来不必要的麻烦。

依赖反转原则：一个良好设计的系统，在源代码层面的依赖关系中需要多(duō)引用(yòng)抽象类型，而非具體(tǐ)实现。因為(wèi)抽象层是稳定的，我们会经常修改接口的具體(tǐ)实现，而很(hěn)少去修改对应的抽象接口，那么当我们修改具體(tǐ)实现时，就不会影响对应的接口和相应的服務(wù)调用(yòng)方，实现异构系统的独立性。在架构层面，是说各个系统之间需要组成有(yǒu)向无环图，确保系统之间不会出现相互依赖。

以上SOLID原则虽然是说具體(tǐ)代码层面的，但是对于系统架构设计层面的也有(yǒu)相应的指导思想，这里我们只需理(lǐ)解其背后想表达的理(lǐ)念并加以灵活运用(yòng)，而不必纠结于名称或者是具體(tǐ)适用(yòng)范围。

【结束语】

近年来，业界又(yòu)提出了无服務(wù)器架构，即serverless架构。它是这样描述的，无服務(wù)器架构是基于互联网的系统，其中应用(yòng)开发不使用(yòng)常规的服務(wù)进程。而是将服務(wù)托管于例如亚马逊的Lamda服務(wù)等第三方服務(wù)。

Serverless架构也是一种微服務(wù)的架构，只不过它可(kě)以提供更碎片化的软件架构模式，即FaaS(Function as a Service)。FaaS是基于函数的编程，它是相比于微服務(wù)更加细小(xiǎo)的程序单元，我们可(kě)以针对一个函数来进行单独的扩展和优化。Serverless在降低运营成本，提升扩展能(néng)力等方面具有(yǒu)很(hěn)大的优势。

可(kě)以发现，在系统架构的演进过程中，我们不断的将功能(néng)拆分(fēn)為(wèi)更加细颗粒度的、可(kě)以单独部署和扩展的异构系统。但是，采用(yòng)什么样的架构，是需要根据项目和人员的具體(tǐ)情况来决定的，并且在项目的迭代工程中进行评估和调整的，最后选择一个适合的系统架构而切忌盲目跟风。