分布式服务架构(一)---服务架构的进化史

一 前言

  基于现在的分布式框架火了很久，其面对大规模海量用户的数据处理的优势,本人创建一个分布式服务架构的分类，专门整理一些关于此服务架构的详细教程，若有不足之处望多多指教！

二 从传统单体架构到服务化架构

传统的单体架构框架最常用的无非是SSH以及SSM框架，就拿SSM框架来说，其结构如下图所示

大多数企业里 的 SSM 架构最终会被打包到同 一个 JEE 规范的 War包里，并且部署在ApacheTomcat Web 容器 里 ，因此，整个结构还是趋向于传统的单体架构，业务逻辑仍然糯合在一个项目中，即使通过规范来约束模块化组件的精合度，效果也往往适得其反。

这种框架服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有组件精合在一个开发项目中，并且配置和运行在一个口叫进程中 。 如果某个模块化组件需要升级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的 变更，由于种种原因，会导致其他模块化组件出现问题。

后来为了解决以上的问题：

   出现了一种面向服务的架构SOA:SOA 将应用程序的模块化组件通过定义明确的接口和契约联系起来，接口是采用中立的方式进行定义的，独立于某种语言、硬件和 操作系统，通常通过网络通信来完成，但是并不局限于某种网络协议，可以是底层的TCP/IP，可以是应用层的 HTTP ，也可以是消息队列协议，甚至可以是约定的某种数据库存储形式。这使得各种各样的系统中的模块化组件可以以一种统一和通用的方式进行交互。

SOA 的两个主流实现方式： Web Service 和ESB。

 1.WebService:

Web Service 的工作原理如下。

· 服务提供者WebService 2 和 Web Service 3 通过 UDDI 协议将服务注册到 Web Service 目录服务中。

· 服务消费者 WebService l 通过 UDDI协议从 Web Service 目录中查询服务，并获得服务 的 WSDL 服务描述文件。

· 服务消费者 WebService 1 通过 WSDL 语言远程调用和消费 WebService 2和 Web Service 3 提供的服务。

好比：阅读一本书，你要找某个章节，最快的方法就是先去找书的目录，通过目录再去找你章节所在的页码。

关于webService：不清楚的朋友可以去我的webService分类里面查看其具体的实现

2.ESB

ESB 是企业服务总线的简称，是用于设计和实现网络化服务交互和通信的软件模型，是 SOA 的另一种实现方式，主要用于企业信息化系统的集成服务场景中。

我们看到企业服务总线是 ESB 的核心要素，所有服务都可以在总线上插拔，并通过总线的流程编排和协议转接能力来组合实现业务处理能力。

三 从服务化到微服务

随着互联网的迅速发展，用户越来越多，当海量用户同时发起请求的时候，不得不面对大规模高并发的问题，之前所讲到的SOA服务化框架，在面对这个问题的时候，暴露了各自的不足：

Web Service 的问题如下：

• · 依赖中心化的服务发现机制。
• · 使用 SOAP 通信协议，通常使用 XML 格式来序列化通信数据， XML 格式的数据冗余 太大，协议太重。
• · 服务化管理和治理设施并不完善。

ESB 的问题如下:

• ESB 虽然是 SOA 实现的一种方式，却更多地体现了系统集成的便利性，通过统一的服 务总线将服务组合在一起，并提供组合的业务流程服务 。
• · 组合在 ESB 上的服务本身可能是一个过重的整体服务，或者是传统的 JEE 服务等。
• ESB 视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在 。
• · 对于总线本身的中心化的管理模型，系统变更影响的范围经常会随之扩大 。

 随着技术的发展，微服务的出现解决了以上的问题微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务， 子服务之间通过良好的接口定义通信机制，通常使用 RESTful 风格的 API 形式来通信 ，因为 RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP 协议有跨语言、跨异构系统的优点， 

四 微服务架构与传统架构的区别

微服务架构图：

• · 微服务把每一个职责单一 的功能放在一个独立的服务中，每个服务运行在一个单独的进程中 。
• · 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息 队列等资源。
• · 每个服务应该有自己的运营平台，以及独享的开发人员以及技术人员
• · 每个服务都可根据性能需求独立地进行水平伸缩 。

单体结构图

• 传统单体架构将所有模块化组件混合后运行在同一个服务的JVM进程中。
• ·可对包含多个模块化组件的整体的JVM进程进行水平扩展，而无法对某个模块化组件进行水平扩展。
• · 某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线。
• · 久而久之，模块间的依赖将会不清晰、互相依赖成为家常便饭。

五 微服务架构与SOA的区别

     1.目的不同

SOA 服务化涉及的范围更广一些，强调不同的异构服务之间的协作和契约 并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和 ESB。

·微服务使用一系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和法代影响的范围，并达到单一微服务更容易水平扩展的目的。

     2.部署方式不同

· 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术 来实现自动化的容器管理，每个微服务运行在单一的进程内，微服务中的部署互相独立、互不影响。

(关于Docker:Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。)

• SOA 服务化通常将多个业务服务通过组件化模块方式打包在一个 War 包里，然后统一 部署在一个应用服务器上。

3. 服务粒度不同

· 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆分 到职责单一，甚至小到不能再进行拆分。

• SOA 对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。