软件架构综述知识

一、软件架构的定义

1、软件架构的概念

软件架构（software architecture）是一个系统的草图,是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

 软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”一书中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”

2、与软件体系结构概念的细微区别

目前，没有文献表明软件体系结构与软件架构的差别。如果你强调方法论，应使用软件体系结构。强调软件开发实践，应使用软件架构。构架不仅是结构，IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

　　软件系统的架构是一个软件系统从整体到部分的最高层次的划分。其有两个要素：元件划分和设计决定。详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

3、研究的背景

   在经历60年代的软件危机之后,使人们开始重视软件工程的研究。来自不同应用领域的软件专家总结了大量的有价值的知识. 当初,人们把软件设计的重点放在数据结构和算法的选择上，如Knuth提出了数据结构+算法=程序. 但是随着软件系统规模越来越大、越来越复杂，使软件系统的架构越来越重要。软件危机的程度日益加剧，现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说，软件体系架构比起对程序的算法和数据结构的选择已经变得明显重要得多。在此种背景下，人们认识到软件体系架构的重要性，并认为对软件体系架构系统、深入的研究将会成为提高软件生产效率和解决软件危机的最有希望的途径

二、架构的目标

　　正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

·可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

·可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

·可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

·可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

·客户体验（Customer Experience）。软件系统必须易于使用。

·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

三、架构的种类

　　根据我们关注的角度不同，可以将架构分成三种：

·逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

·物理架构：软件元件是怎样放到硬件上的。

·系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

四、架构的风格

  软件体系结构风格（有时候也叫架构模式）是描述某一特定应用领域中系统组织方式的惯用模式，是为一个系统提供的一系列抽象框架。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。架构风格通过为经常发生的问题提供解决方案，来提高设计重用和改善程序结构。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

    通用软件体系结构风格总结为以下几类：     

1.数据流风格：批处理序列；管道过滤器。

2.调用返回风格：主程序子程序；面向对象风格；层次结构。

3.独立构件风格：进程通讯；事件系统。

4.虚拟机风格：解释器；基于规则的系统。

5.仓库风格：数据库系统；超文本系统；黑板系统。  

    几种主要的和经典的体系结构风格：

1.C2风格。C2风格是最常用的一种软件体系结构风格，该体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统，抽象数据类型概念对软件系统有着重要作用。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

5.批处理风格。批处理风格的每一步处理都是独立的，并且每一步是顺序执行的，只有当前一步处理完后，后一步处理才能开始，数据传送在步与步之间作为一个整体。批处理的典型应用是经典数据处理和程序开发。

6.仓库风格。在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

五、常用的软件架构

一、C/S 架构

优点：C/S 体系结构的优点主要在于系统的客户应用程序和服务器构件分别运行在不同的 计算机上，

系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示 出极大的适应性和灵活性，而 且易于对系统进行扩充和缩小。在 C/S 体系结构中，系统 中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务 器的开发则集中于数据的管理，不必在每一个新的应用程序中都要 对一个 DBMS 进行编 码。将大应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

缺点：

①开发成本较高。C/S 体系结构对客户端软硬件配置要求较高，尤其是软件的不断升级，对硬件要求不断提高，增加了整个系统的成本，且客户端变得越来越臃肿。

②客户端程序设计复杂。釆用 C/S 体系结构进行软件开发，大部分工作量放在客户端的程序设计上，客户端显得十分庞大。

③信息内容和形式单一，因为传统应用一般为事务处理，界面基本遒循数据库字段解释，开发之初就已确定， 而且不能随时截取办公信息和档案等外部信息，用户获得的只是单纯的字符和数字，既枯燥又死板。

④用户界面风格不一，使用繁杂，不利于推广使用。

⑤软件移植困难。采用不同开发工具或平台开发的软件一般互不兼容，不能或很 难移植到其他平台上运行。

⑥软件维护和升级困难。采用 C/S 体系结构的软件要升级，开发人员必须到现场 为客户机升级，每个客户机上的软件都需维护。对软件的一个小小改动（例如只改动一 个变量)，每一个客户端都必须更新。

二、三层 C/S 架构

这种客户机称为瘦客户机（thin client）。三层 C/S 架构将应用系统分成表示层、功能层和数据层三个部分。

①表示层。表示层是系统的用户接口部分，担负着用户与系统之间的对话功能。它用于检查用户从键盘等输入的数据，显示输出的数据。

②功能层。功能层也称为业务逻辑层，是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额、按照预定的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。

③数据层。数据层相当于二层 C/S 架构中的服务器，负责对 DBMS 的管理和控制。

三、B/S 架构

基于 B/S 体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块。真正达到了“零客户端”的功能，很容易在运行时自动升级。B/S 体系结构还提供了异种机、异种网、异种应用服务的联机、联网等。

与 C/S 体系结构相比，B/S 体系结构也有许多不足之处，例如：

①B/S 体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。

②B/S 体系结构的系统扩展能力差，安全性较难以控制。

③采用 B/S 体系结构的应用系统，在数据査询等响应速度上，要远远地低于 C/S 体系结构。

④B/S 体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理 OLTP 应用。

多层架构的优点：

开发人员可以只关注整个结构中的其中某一层；

可以很容易的用新的实现来替换原有层次的实现；

可以降低层与层之间的依赖；

有利于标准化；

利于各层逻辑的复用；

扩展性强。不同层负责不同的层面；

安全性高。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。

项目结构更清楚，分工更明确，有利于后期的维护和升级。

多层架构的缺点：

严格的分层可能导致性能问题，具体取决于层数。

建立清晰的分层架构并不总是很容易。

四、面向服务的架构 SOA

SOA 架构中所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务

通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。

SOA 架构将应用程序的不同功能单元按照服务模块拆分成多个子系统，这样做的优势：

（1）把系统按服务模块拆分，各个模块独立开发，独立部署，互不影响，大幅降低了模块之间的耦合度，各个服务模块后面可以使用不同的技术；

（2）把项目拆分成若干个子项目，不同的团队负责不同的子项目，大幅度提高团队的开发和生产效率；

（3）增加业务子系统时只需要增加一个子应用项目，调用服务就可以快速组装子应用，提高了程序的复用性，可以更快速的进行业务创新；

（4）可以灵活的进行分布式部署，更好的支持在线业务。

在 SOA 架构中，继承了来自对象和构件设计的各种原则，例如，封装和自我包含等。那些保证服务的灵活性、松散耦合和复用能力的设计原则，对 SOA 架构来说同样是非常重要的。关于服务，一些常见的设计原则如下：

（1）明确定义的接口。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使用；不要让请求者看到服务内部的私有数据。

（2）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

SOA 架构中的关键技术：

（1）SOAP：简单对象访问协议，Simple Object Access Protocol

（2）WSDL：Web 服务描述语言，Web Services Description Language

（3）UDDI：统一描述、发现和集成，Universal Description Discovery and Integration

WSDL 用来描述服务，UDDI 用来注册和查找服务，而 SOAP 作为传输层，用来在消费这和服务者之间传送消息，一个消费者可以在 UDDI 注册表查找服务，取得服务的 WSDL 描述，然后通过 SOAP 来调用该服务。

（4）REST

REST 提出了如下一些设计概念和准则：

①网络上的所有事物都被抽象为资源。

②每个资源对应一个唯一的资源标识。

③通过通用的连接件接口对资源进行操作。

④对资源的各种操作不会改变资源标识。

⑤所有的操作都是无状态的。

目前，实现 SOA 的方法也比较多，其中主流方式有 Web Service、企业服务总线和服务注册表。

（1）Web Service

在 Web Service（Web 服务）的解决方案中，一共有三种工作角色，其中服务提供者和服务请求者是必须的，服务注册中心是一个可选的角色。它们之间的交互和操作构成了 SOA 的一种实现架构。

（2）服务注册表

服务注册表（service registry）虽然也具有运行时的功能，但主要在 SOA 设计时使用。它提供个

策略执行点（Policy Enforcement Point，PEP），在这个点上，服务可以在 SOA 中注册，从而可以被发现 和使用。服务注册表可以包括有关服务和相关构件的配置、依从性和约束文件。从理论上来说，任何帮助 服务注册、发现和查找服务合约、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个 注册表。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。

（3）企业服务总线 ESB

是 SOA 的一种实现方式, ESB 在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合，主要作 用：

描述服务的元数据和服务注册管理；

在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一 些模式如同步模式、异步模式等；

发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一 些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。

五、微服务架构

微服务优点：

（1）每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。

（2）微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。

（3）微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

（4）微服务能使用不同的语言开发。

（5）去中心化。每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

微服务缺点：

（1）很难在不采用分布式事务的情况下跨服务实现功能

（2）测试工作更加困难

（3）跨服务实现要求功能要求团队之间的紧密协作

（4）部署复杂

在微服务中，应用网关 API 的作用:

（1）提供统一入口

（2）可以进行权限身份认证等安全管理

（3）可以根据流量进行限流

（4）数据缓存

（5）性能监控等

（6）异常重试

（7）服务降级

六、轻量级架构

（1）SSH：指的是 Struts2(做前端控制器)，Spring(管理各层的组件)，Hibernate(负责持久化层)

（2）SSM：指的是 SpringMVC(做前端控制器)，Spring(管理各层的组件)，Mybatis(负责持久化层)

Hibernate 与 Mybatis 区别：

①开发方面：在项目开发过程当中，就速度而言，hibernate 开发中，sql 语句已经被封装，直接可以使用，加快系统开发；Mybatis 属于半自动化，sql 需要手工完成，稍微繁琐。

②sql 优化方面：Hibernate 自动生成 sql,有些语句较为繁琐，会多消耗一些性能；Mybatis 手动编写 sql，可以避免不需要的查询，提高系统性能；

③对象管理方面：Hibernate 是完整的对象-关系映射的框架，开发工程中，无需过多关注底层实现，只要去管理对象即可；Mybatis 需要自行管理映射关系；

④ 缓存方面：Hibernate 在使用二级缓存时如果出现脏数据，系统会报出错误并提示。Mybatis 脏读不报错。

六、关于架构

1、EAI与SOA之比较

EAI是将基于异构平台下的业务应用系统集成在一起的一种技术。EAI通过中间件作为粘合剂来连接企业内外各种业务相关的异构系统、应用以及数据源，从而满足企业内部应用系统之间信息共享的需要。

SOA(面向服务的体系结构)将企业中各个系统应用程序的不同功能单元抽象为服务，通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务能够通过统一和通用的方式进行交互。SOA架构由服务总线、服务目录、门户、流程管理等几个核心组件构成的。这些核心组件协同工作共同支撑服务的部署、运行与管理监控。

从以下的几个方面对EAI与SOA进行比较：

1. 集成的本质

EAI的集成方式从本质而言是基于消息的集成，因此EAI的各组成部件，如适配器与hub，都带有消息转换与消息路由的功能，在EAI的运作过程中，单个应用系统只关心其与EAI连接部分消息的输入与输出，不关心具体的业务处理，业务处理都是在应用系统内部完成的。

SOA的集成方式，其本质是对业务功能服务化后根据业务流程进行编排，是真正意义上的基于功能服务的集成。当然在基于SOA的集成中同样包含了基于消息集成的功能。

因此基于SOA的集成方式比EAI的集成方式适用范围更广。

2. 集成对象的颗粒度

SOA和EAI从不同的视角切入去看待企业已有的信息资源，并基于此对企业已有的资源进行梳理、分类和集成。

    EAI从应用系统的层面去看待企业已有信息资源，企业的每一个应用系统被看作一个集成单元，EAI工作的目标就是，通过为这些已有的应用系统提供一种中间沟通方式，让这些应用软件之间可以进行数据的共享与交换，从而盘活这一个个独立的“信息孤岛”。

   SOA从提供服务、使用服务的角度去看待企业已有的信息资源。在这种方式下，同样的一种资源既可能是服务提供者，也同样可以是服务使用者； 在这种方式下，一个应用模块可能只提供一种服务，因此被封装成一个服务，也可能由于提供了多种服务，而需要进一步划分。

显然，SOA方式集成处理的颗粒度比EAI要小，因此SOA方式比EAI方式更具有灵活性。

3. 标准化

SOA在实现企业信息化集成的同时，也将实现企业级服务的高度可重用作为目标，因此，在SOA架构中任何一种接口、通讯、协议都是遵循相应的国际标准，如：标准描述语言（WSDL）、发现协议（UDDI)和消息协议(SOAP)等。

EAI则大多使用基于具体实施EAI企业中制定的私有标准。基于私有标准的优点是可以在一定程度上减轻EAI中间层对应用系统消息翻译转换的压力，在应用系统较少的情况下可以提高EAI的整体性能，但私有标准同时也对企业整合的灵活可扩展性上带来损失，当企业引入新的应用系统，或当某个应用系统需要做比较大的改动时，整个EAI总线的适应性将变得十分脆弱。

在系统较少的情况下或是系统集成的早期阶段，采用私有标准的EAI会体现出性能高，实现难度低等优点，但在企业规模不断增长的过程中，新引入系统的整合难度将因为标准的不统一而呈指数级上升。

4. 灵活可扩展性

由于对标准的良好支持，使得SOA具有可灵活扩展的特性，而EAI要达到同样的扩展效果，其代价将远远高于SOA。例如，现在有甲、乙两个系统需要集成。假设它们通过SOA完成集成形成A方案，使用EAI完成集成形成B方案。当集成需求发生变化后，甲乙两个系统需要以另外一种业务逻辑进行集成。对于A方案而言，所需要做的工作比较简单，只需将之前的业务逻辑打开，重新组合一下业务逻辑就可以实现。而对于B方案而言，过程就会麻烦的多，需要根据新的业务逻辑，重新设计开发满足新业务逻辑需要的适配器和中间层的消息处理逻辑。

5. 重用性

企业信息化建设的投资可以分为两个部分：现有应用系统的维护与新系统的开发费用。在SOA架构下，各个服务是以完全独立的方式通过服务目录暴露在SOA集成平台上的，当新集成进来的应用系统需要使用现有的某个服务时，可以直接使用，无需再次开发，即服务是可重用的，只需用开发目前还没有的业务功能服务，这样可以充分利用现有的资源，降低成本。

通过EAI方式实现企业应用集成，其开发的适配器、中间层消息转换规则和消息路由都是紧耦合的，当新系统要在EAI中进行集成，便需要对现有的部分适配器、中间层消息转换规则与消息路由进行改造，无法重用。

因此，使用SOA比使用EAI更经济，尤其在多个应用系统相互集成的复杂场景下，SOA的优点将更加突出。

6. SOA企业服务总线与EAI总线的比较

ESB(Enterprise Service Bus企业服务总线）是一种用于推动SOA的基础设施，从技术上而言，企业服务总线是一种消息传递的主干线，它用于提供协议转换，消息格式的转换，地址路由，接收并分发从各个连接到ESB的服务请求与系统传递来的消息。

在EAI的总线架构中，EAI为消息传播提供了一个中央消息主干线---Bus。应用程序使用适配器将消息发布到总线，消息通过总线流动到预订的应用程序中。总线是消息流动的通道，捆绑在应用软件端的适配器负责将消息在应用程序端的格式与符合总线标准的格式之间转换。因此，对于每一个应用程序，都需要单独为其开发符合应用程序自身要求的适配器，而由于没有遵循统一的标准，这些适配器是无法通用的。当某个应用系统进行比较大的改动时，则有可能存在对适配器的改造已经不能满足系统变更需求的情况，此时甚至有可能会牵涉到对BUS总线的修改，给企业信息架构带来很大的风险。

从ESB和EAI的总线工作过程上的区别可以看出ESB承担了更多的责任，做了更多的事情，为集成后的系统提供了完善、坚固的底层支持。而EAI的总线，只是一个消息的分发器。功能上的差别导致了系统集成到总线上的代价的巨大差异。

7. 系统集成的代价

SOA架构中的企业服务总线与EAI中私有形式BUS尽管结构较为相似，但是在系统集成中却导致集成的成本代价却有很大的差别。这种在代价上的差异主要由两个方面的因素造成的，一是私有形式的总线提供很多产品套件式的内建函数功能，这些函数功能需要根据业务需求进行开发；二是很多的私有形式的总线采用专有的消息格式来提高性能，但却增加了系统开发代价。企业服务总线都是基于标准的。企业服务总线主要的优点就是相比集线器架构和基于产品套件的总线架构的支出要低，而且它是完全基于业界标准化。

另一个关键的不同是：ESB具有分散的和分布式体系结构，更加轻型的安装，而EAI遵从HUB-SPOKE体系结构，因而企业中进行多个大型应用系统之间的集成时，硬件成本高，扩展性也会相对比较薄弱。.

2、编制和编排的差别

编制(Orchestration)指为业务流程而进行Web服务合成，用于定义合成服务以及重用已有服务的内部流程。面向可执行流程:流程编制使用个可执行中心流程来协同内部及外部Web Service交互通过中心流程来控制总体目标涉及操作服务顺序这种集中化管理使Web服务能够在不了解彼此影响情况下进行添加和删除还允许在出现和异常情况下进行补偿其结果可以看作个新Web Service可以执行只是执行过程需要别Web服务。编制虽然是采用统控制方式但是编制状态为由里向外方式来反映视角集中在具体参和者活动。

编排(Choreography)指为业务协作而进行Web服务合成，用于定义多方如何在一个更大的业务事务中，通过交易伙伴及外部机构交换信息，进行对等的协作。面向合作:更多强调协同工作和业务合作能力通过消息交互序列来控制各个部分资源交互参和交互资源都是对等没有集中控制。例如在供应链方面实施产品采购可能涉及到多家公司定单、发货通知单和资金交互编排不描述每个公司如何处理操作只描述区别公司如何彼此交互实际上我们在具体分析个流程时候经常从Choreography思路方法开始每个参和人部门或公司会告诉我们:“如果我得到了个文档下面我应该做什么……然后传递给XYZ”当他们将流程控制权传递给操作下步骤人部门或公司时候他们对流程控制就结束了当然我们可以使用这种方式来设计流程这种方式流程避免了集中控制可以更好被度量缺点是对整个流程状态控制及分析流程原因是比较困难在个大公司或组织中是没有人了解谁在负责这具体流程。

编制虽然没有采用集中控制但是编制视角是从面向整个系统。

SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

什么是REST？
REST (REpresentational State Transfort) 形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。抛开R. T. Fielding博士论文里晦涩的理论不说，REST应该满足这样的特点：1)客户端和服务器结构；2)连接协议具有无状态性；3)能够利用Cache机制增进性能；4)层次化的系统；5)按需代码。说到底，REST只是一种架构风格，而不是协议或标准。但这种新的风格（也许已经历史悠久？）对现有的以SOAP为代表的Web Service造成的冲击也是革命性的，因为它面向资源，甚至连服务也抽象成资源，因为它和HTTP紧密结合，因为它服务器无状态。
    REST与SOAP的区别：因为SOAP并不假定传输数据的下层协议，因此必须设计为能在各种协议上运行。即使绝大多数SOAP是运行在HTTP上，使用URI标识服务，SOAP也仅仅使用POST方法发送请求，用一个唯一的URI标识服务的入口。举一个图书馆在线查询管理系统为例，服务提供者必须为每一本书提供一个内部标识，然后可能定义一个listBooks操作来返回一系列图书，一个getBook操作来返回指定的图书，一个createBook操作来向数据库加入新增的图书，一个deleteBook操作来删除作废的图书，每个操作都有各自的参数，尤其是用内部标识来标识操作的图书。这种设计被诟病之处，在于deleteBook操作也要用POST方法来发送，而其实HTTP协议有更和逻辑的DELETE方法可用。REST正是这样设计的，REST为每一个资源（此处是图书）指定一个唯一的URI，而用HTTP的4种方法GET、POST、PUT、DELETE直观地表示获取、创建、更新和删除图书。同时图书集合也是和单本的图书不同的资源，如果用/books来代表图书列表，/books/ID来代表标识为ID的图书，那么对/books的GET操作就代表返回整个图书列表，对/books/ID的DELETE操作代表删除指定的图书，等等。
     REST的优点：REST简单而直观，把HTTP协议利用到了极限，在这种思想指导下，它甚至用HTTP请求的头信息来指明资源的表示形式（如果一个资源有多种形式的话，例如人类友善的页面还是机器可读的数据？），用HTTP的错误机制来返回访问资源的错误。由此带来的直接好处是构建的成本减少了，例如用URI定位每一个资源可以利用通用成熟的技术，而不用再在服务器端开发一套资源访问机制。又如只需简单配置服务器就能规定资源的访问权限，例如通过禁止非GET访问把资源设成只读。服务器无状态带来了更多额外好处，因为每次请求都包含响应需要的所有信息，所有状态信息都存储在客户端，服务器的内存从庞大的状态信息中解放出来。而且现在即使一台服务器突然死机对客户的影响也微乎其微，因为另一台服务器可以马上代替它的位置，而不需要考虑恢复状态信息。更多的缓存也变成可能，而之前由于服务器有状态，对同一个URI的请求可能导致完全不同的响应。总体结果是，网络的容错性和延展性都增强了。

什么是微服务？

微服务是一种软件开发技术，是面向服务的体系结构（SOA）架构风格的一种变体。微服务将应用程序构造为一组松散耦合的服务，微服务中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

微服务架构关键原则：

1. 每一个 URI 代表 1 种资源

2. 客户端使用 HTTP Verb 表示操作方式的动词对服务端资源进行操作

3. 通过操作资源的表现形式来操作资源

4. 资源的表现形式是 XML 或者 HTML

5. 客户端与服务端之间的交互是无状态的，客户端每个请求必须包含理解请求所必需的所有信息

微服务的特点是：小细专轻松独。小是相对于服务的粒度而言；细：粒度细微；专：专注于一件事；轻：轻量级的通信机制。松：松耦合的。独：独立性强、独立部署。

微服务的优势：

（1）技术异构性

（2）有弹性

（3）扩展性

（4）自动部署

（5）与组织相匹配

（6）服务之间可组合性

（7）对可替代的优化

微服务的缺点：

（1）分布式系统的复杂度高

（2）开发运维成本高

​（3）可能需要过多的操作

（4）需要提高DevOps应用技巧

（5）对于故障诊断比较难，分布式部署跟踪比单体架构复杂