聊聊软件架构

时间 2019-12-01

原文原文链接

人类的智力存在上限和没法扩容多是人类文明发展的最大障碍。为了解决这一问题，人类发展史上全部的科技发明，无一不是千方百计来扩容脑力。软件做为一种模仿人类脑力活动的“生命体”，在其发展早期，也遇到相似问题，Frederick P. Brooks, Jr.教授著名的“人月神话”观点就是对这一现象的总结。为了解决这一问题，软件科学发展了不少方法论和技术，好比分布式，好比咱们今天的主题：软件架构和模式。html

软件架构概念

什么是软件架构

学习一个概念，若是知道这些概念要为了解决什么问题，解决谁的问题，对深刻掌握它有事半功倍的效果。对于软件架构这个概念，业界并无一个统1、标准的定义，若是要看透看全面，咱们也须要从不一样视角来了解它。程序员

什么是软件架构，不一样视角下，有着彻底不同的解读。算法

从组成的角度看：架构=组件+交互：软件系统的架构将系统描述为计算组件及组件之间的交互。这是《软件构架实践》做者Bass、《企业应用架构模式》做者Martin Fowler等人的观点。shell

从决策的角度看：架构=重要决策集：架构表示对一个系统的成型起关键做用的设计决策，架构定系统基本就成型了，这里的关键性能够由变化的成原本决定。这是UML的创始人Grady Booch等人的观点。数据库

从需求的角度看：架构实际上解决的是人的问题，系统架构的目标是解决利益相关者的关注点。编程

从演化的角度看：架构是用于管理复杂性、易变性和不肯定性，以确保在长期的系统演化过程当中，一部分架构的变化不会对架构的其它部分产生没必要要的负面影响。这样作能够确保业务和研发效率的敏捷，让应用的易变部分可以频繁地变化，对应用的其它部分的影响尽量地小。安全

什么是好的架构

首先，找到全部的利益干系人，并为他们服务。不一样干系人看待架构有不一样的视角，这就是架构视图。架构视图分不少种，常见的有逻辑架构视图、开发架构视图、运行架构视图、数据架构视图和物理架构视图等，这其中最经常使用的是逻辑架构视图和物理架构视图。逻辑视图用于指导设计开发，物理视图用于指导部署运维。服务器

其次，发现并解决利益干系人关注点背后真正的问题。发现问题永远都比解决问题来的更加剧要。网络

最后，符合康威定律，软件架构要与组织架构要一致，只有这样才可以让架构落地并推动。若是不一致，要么调整软件构架，要么调整组织架构。数据结构

软件架构模式

模式（Pattern）其实就是解决某一类问题的方法论。而软件架构模式就是解决某一类软件组织构架问题的通用形式。现有的软件架构模式以下图所示。其中分层架构、事件驱动架构、微服务架构、面向服务架构等在阮一峰的《软件架构入门》一文有较详细的介绍。可是还有很多问题没有谈及，好比，这么多架构模式如何选择？每种架构模式解决什么问题？适用什么场景？本节想对这块重点作下比较说明，算是一个补充。

分层架构模式

适用场景：

复杂系统的各个部分须要独立开发和演进。开发人员的关注点分离，系统模块能够独立地开发维护。

解决问题：

如何保证软件模块能够独立开发和演进，模块间尽量少的交互，模块支持可移植性、可修改性和可重用性等质量属性？

解决方案：

为达到关注点分离，软件以层为单位进行划分，层是一组提供内聚服务模块组合。层经过公共接口对外提供服务，层级调用必须是单向的。

模式缺点：

分层增长了系统的成本和复杂性；
额外的分层逻辑对系统性能有必定影响。

Broker架构模式

适用场景：

分布式系统。其提供的服务分布在不一样服务器上。它们的互连关系、交换信息方式等交互复杂。系统对服务的可用性有较高要求。

解决问题：

如何实现分布式软件系统，让用户不须要感知服务提供方的位置，而且用户和服务提供方之间的绑定关系能够动态变化？

解决方案：

经过Broker组件，解耦客户端和服务端。服务端注册本身到Broker，经过暴露接口的方式容许客户端接入服务。客户端经过Broker发送请求，Broker转发请求到服务端，并将请求的结果或异常返回给客户端。经过使用Broker模式，应用能够经过发送消息访问远程的服务。

这一架构模式容许动态的改变、添加、删除服务端，从客户端的角度，这些都是透明的。

Client -- 须要访问远程服务的客户端
Server -- 服务的提供者
Broker -- 相似于消息的转发器，负责控制和管理集群，Server 启动时向 Broker 注册，从而 Broker 在接到 Client 的消息后能够得知要将消息转发给哪一个 Server，而后在 Server 作出应答或发生异常后再将回应通知给 Client
Client_Proxy -- Client 端的代理层，对 Client 隐藏链接、通信等底层服务，让 Client 在使用远程服务时如同使用本地服务同样简单，他维系了 Client 与 Broker 的通讯和链接
Server_Proxy -- Server 端的代理曾，一样，他接收请求、解包消息，让 Server 与 Broker 的通讯和链接被隐藏
Bridge -- 用于多个集群的复杂网络，协调多个 Broker 的数据、消息等工做

模式缺点：

broker做为间接层，增长了clients和servers间的时延，并且多是通讯瓶颈。
broker是单点失效节点。
broker增长系统复杂性。
broker是易于成为安全攻击的目标。
broker难以测试。

MVC架构模式

适用场景：

包含有人机互动介面（UI）的系统。用户但愿从不一样视角来查看数据，如柱状图、饼状图等。

解决问题：

如何实现用户界面（UI）与应用逻辑的分离，并保证系统能响应用户不一样的输入或对应用数据的修改？当底层应用数据变化时，用户界面的多视角如何建立、维护和协调？

解决方案：

model-view-controller模式将系统划分为3个组成要素：

Model（模型）：应用的数据或状态，以及应用逻辑。
View（视图）：按用户请求显示底层数据，提供给用户的操做界面，是程序的外壳。
Controller（控制）：协调管理model和view间的交互，将用户行为转化为对模型的修改或者对视图的修改。

模式缺点：

引入必定的复杂性，不适用简单的UI系统。
一些UI工具包不支持MVC模型。

管道过滤器（Pipe-And-Filter）架构模式

适用场景：

处理数据流的系统。输入数据后，通过一系列的数据加工转换后输出。数据转换动做重复、独立、可复用，支持并发。

解决问题：

如何将系统切分为可复用、松散耦合的组件，而且组件间的交互足够简单？如何保证组件能够弹性组合，组件通用、低耦合、可复用，而且可并发执行？

解决方案：

管道和过滤器（Pipes and Filters）架构模式由过滤器和管道组成。每一个处理步骤都被封装在一个过滤器组件中 , 数据经过相邻过滤器之间的管道进行传输。每一个过滤器能够单独修改 , 功能单一 , 而且它们之间的顺序能够进行配置。Unix shell管道和编译器都是典型的例子。

过滤器：一种组件，其功能是从输入端口读入数据，进过数据转化后，再将数据写入输出端口输出。
管道：一种链接器，其功能是将数据从一个过滤器的输出端口传输到另外一个过滤器的输入端口。管道的输入源和输出地是单一的。管道不修改其传输的数据。

模式缺点：

共享状态信息或者昂贵或者不灵活。
数据转换额外开销。

CS架构模式

适用场景：

分布式系统。系统中大量的分散的客户端对共享的资源和服务进行访问。

解决问题：

如何在资源和服务分布在多个物理服务器的分布式系统中，经过对共享资源进行集中管理，提升系统的可维护性和可复用性，改进其可扩展性和可用性？

解决方案：

CS架构模式由client和server2个要素组成。server提供服务，client请求server的服务，系统交互由client发起。系统能够有一个中央server，也能够是多个分布式server。

Client：请求Server服务的组件。拥有描述请求服务的接口。
Server：提供服务给Client的组件。拥有描述提供服务的接口。

模式缺点：

Server多是系统性能瓶颈。
Server多是单点失效节点。
系统一旦部署，调整代价大。

P2P架构模式

适用场景：

分布式系统。系统中每一个组件的地位对等，均可以主动发起交互和对外提供服务。

解决问题：

地位对等组件间的互连公共协议如何实现？如何保证系统的高可用性和可扩展性？

解决方案：

P2P模式由peer和connector 2个要素组成。全部的peer地位对等，不是单点失效节点。peer间经过request/reply connector链接并直接交互。

Peer：运行在网络节点上的独立组件。特定peer组件（如图中的超级节点ultrapeer）能够提供路由、索引、查找等功能。

Request/reply connector：用于链接peer网络，查找其余peer节点和调用其余peer节点上的服务。

模式缺点：

数据一致性、数据有效性、数据备份和恢复，安全等实现方案复杂。
对于小的P2P系统，性能、可用性等质量目标较难以达到。

面向服务架构（SOA）模式

适用场景：

异构的分布式系统。服务提供方提供服务，并由用户使用。用户不须要了解服务的实现细节，便可理解和使用它们。

解决问题：

一个系统中，服务组件运行在不一样的平台，由不一样的编程语言开发，由不一样的组织提供，分布在各网络节点中，如何保证这些组件的互操做性？

解决方案：

采用中央管理模式来确保各服务可以交互运做，服务间经过链接件交互，经过网络对外提供或使用服务。SOA模式由以下几个要素组成。

应用服务（Service）：提供服务或调用服务。即服务提供者或服务使用者，或两种角色兼具。
企业服务组件（Enterprise Service Bus）：一种在服务提供者和使用者之间传输、转化消息的中间件。
服务注册：服务提供者经过它注册服务，服务使用者经过它在运行时发现服务。
编排服务：基于商业流程和工做流，协调服务提供者和服务使用者间的交互。
链接件：服务经过链接件进行相互通讯和操做。分为SOAP、RESTful、Asynchronous messaging三种实现协议。

模式缺点：

SOA系统构建复杂，成本高。
没法控制服务的演化。
中间件会引入系统性能开销，服务可能会成为系统性能瓶颈。

微服务架构模式

适用场景：

分布式系统。基于服务的企业应用，支持网页、手机客户端等不一样的访问方式。

解决问题：

单块架构的应用可能过于庞大和复杂，难以维护，严重影响效率。并且没法进行分布式部署和弹性扩容。

解决方案：

微服务架构模式是一种将商业逻辑切分为一系列能够独立开发和部署的服务的架构。其中各项服务都拥有本身的进程，利用轻量化机制或RESTful接口实现通讯。这些服务围绕业务功能创建而成，且凭借自动化部署机制实现独立部署。这些服务匹配一套最低限度的中央式管理机制，且各服务可经过不一样编程语言编写而成，拥有本身独立的数据库，由不一样的开发团队开发。

模式缺点：

微服务有额外成本的，须要搭建框架、发布、监控等基础设施。
微服务架构可能带来过多的操做；由于分布部署跟踪问题难。
微服务应用是分布式系统，会带来固有的复杂性。
随着微服务数量不断增长，其管理复杂性也将增长。

发布订阅架构模式

适用场景：

系统中有大量的独立的数据生产者和数据消费者，数据生产者和消费者的数量和种类动态变化。它们经过数据交互，但数据在它们之间不共享。

解决问题：

如何创建一种消息传输机制，使生产者和消费者之间相互不感知？

解决方案：

发布订阅模式由3个要素组成。组件经过消息或事件交互。发布者将消息发布到总线上，订阅者注册它们感兴趣的事件，订阅管理器负责将这些事件的副本发送给订阅者。

Publisher：经过发布接口发布事件。
Subscriber：经过订阅接口订阅事件。
Subscription Manager：接收发布者发布的事件，并将事件发布给订阅该事件的订阅者。

模式缺点：

增长系统响应时延，对系统的可扩展性和消息传递时间的可预测性有负面影响。
难以控制消息序列。
难以保证消息传递的可靠性。

共享数据架构模式

适用场景：

系统中不一样的计算组件须要共享和操做大量数据，这些数据不单独属于某一个组件。

解决问题：

系统如何存储和操做这些持久化数据？

解决方案：

共享数据模式由三部分组成。

共享数据库：协调数据访问器间的通讯，功能包括数据存储、性能属性、访问控制等。
数据访问器：发起数据访问。只与数据库进行交互。
数据读写链接件：负责数据的读写。

模式缺点：

共享数据库可能会成为系统性能瓶颈。
共享数据库是单点失效节点。
数据的生产者和消费者的耦合度高。

黑板架构模式

适用场景：

一个新兴的或者不成熟的领域，没有肯定的或优化的问题解决方案。软件系统须要集成多种形态不一样的模块，以便实现复杂的、非肯定性的控制策略。如语音识别、如人工智能领域等。

解决问题：

问题设计多个专业子领域，每一个子领域都有一套独立的算法。鉴于领域不成熟，可能须要尝试不一样的算法。由于涉及不可靠的数据，只能求近似解，没法找到最优解。算法的执行顺序不肯定时还可能要求支持并行性。

解决方案：

Blackboard架构模式对还未找到肯定解决策略的问题颇有帮助。在Blackboard模式中，多个专业子系统经过集思广益，得到可能的部分解或近似解。

Blackboard架构背后的理念是，一系列独立的程序携手合做，在公共数据结构（即blackboard）上进行计算，中央控制器根据结果状态对知识源进行协调控制。
在解决问题的过程当中，系统经过合并、修正或否决部分解来完成工做。每一个部分解都针对一个子问题，是这个子问题的最终解在特定阶段的表现形式。全部的可能解构成解空间，并被组织成多个抽象层级，其中最低层为输入的内部表示，最高层包含系统要解决的整个问题的可能解。
之因此使用名称“黑板”(blackboard)，是由于它让人想起专家们站在黑板前协做解决问题的情形。专家们一般自行决定接下来该由谁来到黑板前，而在这里介绍的模式中，若是有多个程序都能提供帮助，将由调停者(moderator)组件决定这些程序的执行顺序。

黑板模式包含3个要素。