软件架构和架构风格

今天给大家分享一下架构方面的东西。都是一些相对基础的东西，有错误的话请指正。

首先我们来介绍一下什么是架构。架构一词来源于建筑，代表系统高层次的一些设计角色。比如建筑领域的一栋大楼的架构，指的就是大楼有多高、每一层有多高、有多少层、每一层包括多少房间、有几部电梯、消防通道在哪里、哪里是卫生间、哪里走线路、给排水管道在哪里等等。都是一些高层次的决策。这些高层次的决策从更高的层面为我们描述了这个系统的梗概、也可以说描绘了系统的蓝图。是对系统高层次的抽象。

架构也被称为体系结构，有很多的定义。个人比较认可的一个定义：架构=构件+交互

这又引出来什么是构件。所谓的构件是指具有一定功能，能独立提供服务或者跟其他构件配合提供服务。构件可大可小，大的可以是独立的服务、系统、子系统、组件。小的可以是模块、对象或方法。在不同的抽象层次上我们能够得到不同的构件。这点跟面向对象中的对象很类似。

从上面架构的定义我们能知道，所谓的架构，就是用来定义软件系统有哪些组件、如何划分组件、组件的职责是什么，同时还用来定义构件之间的交互方式。是通过MQ、RPC或者通过http、或者是直接调用。

上面说的是架构的定义，还要介绍另一个概念：架构风格，或者说体系结构风格。

说到风格，我们说一个人具有什么样的穿衣风格时就可以大概知道搭配方式。比如某人的穿衣风格很骚，我们很容易就想到齐逼短裙、低胸。。。

大家对架构风格不熟悉，但是一定熟悉设计模式。

所谓的 设计模式 就是前人针对特定问题的一套解决方案，或者说是套路。

架构风格也被称为架构模式，换句话说是架构方面的套路。也可以说是前人在架构方面总结出来的，用以解决特定问题的方法。下面来看下官方定义：架构风格是用来描述某一特定应用领域软件系统的组织方式的惯用法，反映了众多系统所具有的结构和语义特性，指导如何使用构件构造一个完整的系统。

这个定义很好，看了跟不看一样。。。都不懂。。总而言之就是针对架构方面的一些套路。总结这些模式的目的是什么呢？是重用！

软件方面的模式可以分为三个层次：代码模式、设计模式、架构模式。

代码模式也可以说是编码时的套路，一些技巧。是最低层次的套路。只能影响某一方法或类中的一些细节。

设计模式解决了一般性的设计问题，影响一个模块内部。是中等层次的重用策略。

架构模式最高层层次的重用策略，实现定义好一些子系统、层，指定他们的责任，并给出把它们组织在一起的法则和指南。

下面我们来介绍一下一些常用的架构风格。包括：管道过滤器风格、面向对象风格、分布式架构、SOA风格、微服务风格等等。

今天我们主要介绍SOA和微服务风格。

SOA 是Service Orientated Architure的缩写，即面向服务架构。表示每一个功能都是通过一个独立的服务来提供，服务定义了明确的可调用接口，服务之间的编排调用完成一个完整的业务。

微服务是指可以部署在单个或多个服务器上的具有一定业务功能的轻量的服务。

在介绍它们之前，先介绍一下架构风格的演化过程，就很容易理解架构风格了。

首先我们来介绍一下单体应用。针对单体的网络应用，我们一般会把它进行分层，比如这里我们把它分成ui层、业务逻辑层和DAO层。

分层的好处是什么呢？

1.通过分离关注点，降低复杂度。

人处理复杂问题的能力是有限的。通过分层可以把相同的职责划分在一起，分析某一层时可以只关注当前层，而不用管其他层。这也是面向对象的一大优点。

2.各层只能与相邻层交互，只要接口定义好，内聚性高耦合度小。功能集中。每一层可以很容易替换。

3.不同的层可以分别部署。

分层只是从逻辑视图方面划分系统有什么逻辑组件。我们可以把不同的层放在不同的机器上。架构的物理视图是用来描述逻辑组件部署到物理机器上的策略。

在单体式应用中，我们不但水平方向上进行分层，还会在垂直方向上对某一层划分模块。

类似下图。

下面来介绍下演化到分布式应用。

分布式应用将系统部署到多台机器、多个位置。也是一种垂直纬度的划分。

有以下几种划分的方法：

1.垂直方向不划分，整体部署。前面通过负载均衡服务如ngix进行负载均衡处理。

缺点：

a.某些业务需要扩充，只能整体部署。

b.某个模块需要升级时只能整体部署。

2.垂直方向切分成多个应用。每个应用分别部署，共同组成完成的系统。

更进一步，如果我们在垂直方向上切分的很细。就变成了下面的结构。

细粒度切分之后就变成了SOA和微服务。

通过上面的单体式架构风格的演化过程能够发现，SOA和微服务架构也是分布式架构的一种。但是各有侧重。

SOA架构的几个特点：

1.松耦合

调用者和服务提供者通过服务注册寻址和调用，耦合度小。

2.接口标准化

SOA中的每个服务遵循一定的接口规范。这些协议是跨平台、跨语言的。

3.粗粒度

SOA中的服务应该尽量的面向业务，与一般定义api提供小粒度的接口的原则不同。

SOA是一种思想、一组规范。它的实现是通过WebService技术来实现的 。

不知道大家有没有调用过Webservice接口。C++调用的话有以下几个步骤：

1.获得服务的wsdl文件。

2.使用gsoap工具生成服务接口头文件。

3.使用gsoap工具生成服务接口代理的实现。

4.在代码里直接对第三步生成的实现进行调用即可。（要设置服务所在的地址）

在webservice中有以下协议栈

UDDI是Universal Description Discovery and Integration的缩写。表示通用发现和描述协议。

SOA中包含三种角色：

服务提供者、服务调用者和服务注册中心。

服务提供者提供服务，并将服务注册到服务注册中心。

服务调用者通过wsdl中的描述调用服务提供者接口。分两次使用，第一次是在开发时通过wsdl获得服务提供的接口进行开发。第二次是在运行时通过wsdl去服务注册中心查询服务位置。

服务注册中心是连接服务提供者和服务调用者的纽带。可选的角色。可选时服务调用者静态绑定服务并调用。

以上是对SOA服务架构的简单介绍。

下面介绍微服务架构。

微服务架构跟SOA架构是很像的，都是将一个粗粒度的应用拆分成细粒度的应用。拆分的粒度和方法不同。

相同点：

1.微服务是对SOA思想的升华。

2.两者都是语言无关、跨平台的。

不同点：

1.微服务强调按照领域进行拆分应用，拆分后的应用可以敏捷开发和部署。

2.微服务倡导服务的细粒度，切分到不能再分为止。SOA只是在接口方面要求规范化。

3.微服务把应用拆分成单个服务，借助容器技术，应用从上至下完全独立，甚至每个应用可以有自己独立的DB。开发运维一体化。而SOA只要求接口独立。内部实现可以不独立。

4.微服务倡导去中心化，将所有的逻辑包括负载均衡、动态路由、服务发现、熔断等通用逻辑放在服务内部。而SOA

微服务的service mesh

服务网格。用来治理微服务复杂性的技术和工具。与服务一起部署，但是对服务透明，形成一个分布式的代理网络。

以sidecar形式部署在服务的两侧，所有的服务通过sidecar进行通信。

sidecar的中文意思是旁边有箱子的摩托车，类似当年鬼子进村的摩托车。sidecar可以实现负载均衡、服务发现、动态路由、熔断等。是去中心的化的核心。