架构杂谈《一》
从传统单体架构到服务化架构的发展历程
典型的单体架构分为三个层级，Web层、业务逻辑层和数据存储层，每个层的指责分别如下：
- Web 层：负责与用户交互或者对外提供接口
- 业务逻辑层：为了实现业务逻辑而设计的流程处理模块
- 数据存储层：将业务逻辑层处理的结果持久化
将不同的模块化组件聚合后运行在通用的应用服务器上。
单体架构已经对企业级应用的整体架构进行了逻辑分层，包括了上面提到的Web层、业务逻辑层和数据存储层，不同的层级有自己的职责，并从功能类型上划分层级，每个层级的职责单一。
在这一时期，由于架构上把整体的单体系统分成具有不同指责的层级，对应的项目管理也倾向于把大的团队分成不同的职能团队（UI团队、后台业务逻辑处理团队（程序员）和DBA团队），每个团队只对自己的职责负责。架构已经在一定程度上进行了逻辑的划分。但是，每个层次的多个业务逻辑的实现会被放在同一应用项目中，并运行在同一个.Net CLR或者JVM中，尽管会使用规范来约束不同业务逻辑的隔离性来解耦，但随着复杂业务逻辑的迭代增加及开发人员的不断流动或者为了节省时间和赶进度，非法使用了其他组件的服务，业务组件之间、UI组件之间、数据存储之间的耦合性必然会增加，最后导致组件与组件之间难以划清界限，完全耦合在一起，将来新的功能迭代、增加和维护将会难上加难。
在（JEE、ASP.Net WebForm）等开始流行但没有奠定地位的时候，开源软件Struts、Spring和Hibernate开始浮出水面了，很快成为了行业内企业开发的开源框架标配（SSH）（.Net 的 Asp.Net MVC）,Web MVC 框架在用户交互的UI层进一步划分了前端的职责，将用户交互层划分为了视图（View）、模型（Model）和控制器（Controller）三大块（简称MVC架构），结构图如下：
在这个时代、Struts MVC和Asp.net MVC 模板几乎服务于大多数企业服务的Web项目。后来，开源框架Spring的发布，更加改变了一开始指定的战略目标。Spring有两大核心思想：IOC和AOP。（后单体架构）
从单体架构后后单体架构，服务的特点仍然是单体化，服务的粒度抽象为模板化组件，所有的组件耦合在一个项目中。并且配置和运行在一个.Net CLR(JVM)进程中。如果某个模块化需要升级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的变更，由于各种原因会导致其他模块化组件出现问题。另外在互联网的突飞发展下，传统的单体架构和后单体架构无法满足对大量用户发起的高并发请求进行处理的需求，无法破解耦合在一起的模块化组件的性能瓶颈，单一进程已经无法满足需求，并且水平扩展的能力也是有限的。
为了解决上述问题，SOA就应运而生了。SOA代表面向服务的架构（服务化），SOA将应用程序的模块化组件通过定义明确的接口和约定（契约）联系在一起，接口采用中立的方式进行定义，独立于某种语言、硬件和OS（操作系统），通常通过网络通信来完成，但并局限于某种网络协议（可以是TCP/IP，也可以是HTTP，也可以是消息队列，甚至可以是约定的某种数据库存储形式），这使得各种各样系统中的模块化组件可以以一种统一和通用的方式进行交互。
通过对比各个时代架构下的模块化组件，可以发现SOA将模块化组件从单一进程中进一步拆分，形成了独立的对外提供服务的网络化组件，每个网络化组件通过某种协议对外提供服务，这种架构有以下特点：
- SOA定义了良好的对外接口，通过网络协议对外提供的服务，服务之间表现为松耦合性（松耦合性具有灵活的特点，可以对服务流程进行灵活组装和编排，而不需要对服务本省做任何改变）
- SOA可以让企业最大化地使用内部和外部提供的公共服务
- SOA的数据通信格式通常为XML（冗余的标记会给性能带来极大的影响，后来被JSON取代）
- 组成整个业务流程的每个服务的内部结构和实现在发生改变时，不影响整个流程对外提供的服务（只要对外的接口不变，则改变服务内部的实现机制对外部来说是透明的）
- SOA定义了标准的对外接口，可以让底层通用服务进行下沉，供多个上层的使用方同时使用，增加了服务可重用性
要彻底理解SOA服务化发展情况，必须要了解SOA的两个主流实现方式：Web Service 和 ESB
Web Service
Web Service 技术是SOA服务化的一种实现方式，它使得运行在不同的机器及OS（操作系统）上的服务的互通发现和调用成为可能，并且可以通过某种协议交换数据
通过上图可以看出，每个服务之间是平等的，并且互相解耦的，通过WSDL定义的服务发现接口进行访问，并通过SOAP协议进行通信。SOAP协议通常是一种在HTTP或者HTTPS上传输XML数据来实现的协议，但是每个服务都要依赖中心Web Service来发现现存的服务。
Web Service的工作原理如下：
1、服务提供者通过UDDI协议将服务注册到中心Web Service目录中
2、服务调用者通过UDDI协议从中心 Web Service目录中查询服务，并获得服务的WSDL服务描述文件
3、服务调用者通过WSDL语言远程调用服务提供者提供的服务
通过这个过程，要改造一个新的业务流程，可以从 Web Service 目 录中发现现有的服务，并最大限度地重用现有的服务，经过服务流程的编排来服务新的业务 。
ESB
ESB 是企业服务总线的简称，是用于设计和实现网络化服务交互和通信的软件模型，是SOA的另一种实现方式，主要用于企业信息化系统的集成服务场景中。
在SOA服务化发展之前，企业对信息化系统进行了初步建设，在现有的服务系统上增加新的功能或者叠加新的服务化系统，这需要对这些现有的信息化系统和新增的系统进行组合（如果在现有的系统上使用新的开发、操作系统等等是不现实的，有可能现有的系统是采用异构技术栈实现的）。SOA的松耦合特点正好应用于这一场景。使得企业可以按照服务化的方式来添加新的服务或升级现有的服务，来解决新业务对流程编排的需要，甚至可以通过不同的渠道来获得外部服务并与企业现有的应用进行组合。来提供新的业务场景所需要的信息化流程。
ESB 也使用于事件处理、数据转换和映射、消息和事件异步队列顺序处理、安全和异常处理、协议转换和保证通信服务的质量等场景。
从上图可以看出ESB没有中心化的服务节点，每个服务提供者都是通过总线的模式接入系统，总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务
进行处理。
总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务进行处理。 如下所述
- 监控和控制服务之间的消息路由
- 控制可插拔的服务化的功能和版本
- 解析服务之间交互和通信的内容和格式
- 通过组合服务、资源和消息处理器来统一编排业务需要的信息处理流程
- 使用冗余来提高服务的备份能力
企业服务总线是 ESB 的核心要素，所有服务都可以在总线上插拔，并通过总线的流程编排和协议转接能力来组合实现业务处理能力。
说明：
1、文中的图都来自于百度图片
2、参考书籍：《分布式服务架构：原理、设计与实战》