架构杂谈《一》

架构杂谈《一》

 

从传统单体架构到服务化架构的发展历程

　　典型的单体架构分为三个层级，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的工做原理以下：

　　　　　　一、服务提供者经过UDDI协议将服务注册到中心Web Service目录中

　　　　　　二、服务调用者经过UDDI协议从中心 Web Service目录中查询服务，并得到服务的WSDL服务描述文件

　　　　　　三、服务调用者经过WSDL语言远程调用服务提供者提供的服务

　　　　经过这个过程，要改造一个新的业务流程，能够从 Web Service 目 录中发现现有的服务，并最大限度地重用现有的服务，通过服务流程的编排来服务新的业务 。 

• ESB

　　 ESB 是企业服务总线的简称，是用于设计和实现网络化服务交互和通讯的软件模型，是SOA的另外一种实现方式，主要用于企业信息化系统的集成服务场景中。
　　 在SOA服务化发展以前，企业对信息化系统进行了初步建设，在现有的服务系统上增长新的功能或者叠加新的服务化系统，这须要对这些现有的信息化系统和新增的系统进行组合（若是在现有的系统上使用新的开发、操做系统等等是不现实的，有可能现有的系统是采用异构技术栈实现的）。SOA的松耦合特色正好应用于这一场景。使得企业能够按照服务化的方式来添加新的服务或升级现有的服务，来解决新业务对流程编排的须要，甚至能够经过不一样的渠道来得到外部服务并与企业现有的应用进行组合。来提供新的业务场景所须要的信息化流程。

　　ESB 也使用于事件处理、数据转换和映射、消息和事件异步队列顺序处理、安全和异常处理、协议转换和保证通讯服务的质量等场景。

　　

　　　从上图能够看出ESB没有中心化的服务节点，每一个服务提供者都是经过总线的模式接入系统，总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务
进行处理。

　　总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务进行处理。 以下所述

• 监控和控制服务之间的消息路由
• 控制可插拔的服务化的功能和版本
• 解析服务之间交互和通讯的内容和格式
• 经过组合服务、资源和消息处理器来统一编排业务须要的信息处理流程
• 使用冗余来提升服务的备份能力
  

　　企业服务总线是 ESB 的核心要素，全部服务均可以在总线上插拔，并经过总线的流程编排和协议转接能力来组合实现业务处理能力。

  说明：

　　一、文中的图都来自于百度图片

　　二、参考书籍：《分布式服务架构：原理、设计与实战》