java微服务-各种架构比较

单体架构就是将所有功能都部署在一个web容器中运行的系统就叫做单体架构，一个实例中集成了一个系统的所有功能，通过负载均衡软件/设备实现多实例调用。

单体架构在初创公司、中小型系统、产品试错等场景下开发的周期快、对开发人员的技能要求低而任然被广泛地采用。

优点：
1.易于开发 - 当前开发工具和IDE的目标是支持单片应用程序的开发
2.易于部署 - 只需在适当的运行时上部署WAR文件（或目录层次结构）
3.易于扩展 - 可以通过在负载均衡器后面运行应用程序的多个副本来扩展应用程序

缺点：
复杂性高
项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐，整个项目非常复杂。

部署频率低
随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响的范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。

扩展能力受限
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，我们不得不在硬件的选择上做出妥协。

开发效率低 
每个成员都需要有完整的环境依赖，开发环境的搭建成本高，协同开发时版本冲突频繁，一个有问题的提交可能会影响其他所有同事的开发调试。达到一定代码量后编译慢启动慢

技术升级困难
牵一发而动全身，无法模块化地实现技术框架地升级。在项目生命周期内我们不可能不去升级依赖框架/类库的版本，更有甚者会重新选择基础框架，每一次变更都会伤筋动骨，但我们又不得不做，项目要可持续，温和的、可循序渐进的技术升级达不到，阻碍技术创新

不利于安全管理
所有开发人员都拥有全量代码，在安全管控上存在很大风险，尤其是对用大量外包人员或新招大量开发人员的团队。

SOA
了解到单体架构的这些不足后,自然而然地要做拆分，可以从业务上将不同的模块拆分到不同的系统中。还可以将同一模块进一步拆分，可以按技术分层将一个模块拆分成多个。而无论怎么拆分都会面临一个问题：拆分后的服务怎么调度？

SOA（Service-Oriented Architecture）是一种分布式服务架构的常见方式：提供一种被各个服务单元/系统彼此认可的协议进行数据通讯，进而实现跨服务单元/系统交互的能力。
SOA在软件工程及IT行业的发展中有着举足轻重的地位，在系统标准化、集成化、规模化建设中起到了关键作用。它的核心优势是以相对简单的方式解决了系统间的服务重用问题。为各个独立的、松散的系统互通提供了解决方案。

SOA是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

架构特点：
系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是有序。

系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是复用。

业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是高效。

优点：
①服务之间通过简单、精确定义的接口进行通信，不涉及底层编程接口和通信模型。
②粗粒度性：粗粒度服务提供一项特定的业务功能，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够了。
③松耦合性：松耦合性要求SOA架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系。这样的好处有两点，首先是具有灵活性，其次当组成整个应用程序的服务内部结构和实现逐步地发生变化时， 系统可以继续地独立存在。而紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时 这种结构就显得非常脆弱。
④位置透明性：位置透明性要求SOA系统中的所有服务对于其调用者来说都是位置透明的，也就是说，每个服务的调用者只需要知道想要调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪。
⑤协议无关性：协议无关性要求每一个服务都可以通过不同的协议来调用。
另外，在许多传统的IT系统的内在部分采用的是硬连接，这种结构很难让企 业快速响应市场的变化，而SOA能够重复利用企业现有的资源，可以减轻企业运营成本，提升资源的使用效率，并且减轻企业维护人员的工作量，减少潜在的风险 以及管理费用。

在业务方面和IT方面带来许多优势：
①服务给精确的业务流程带来灵活性；
②使用服务来改善客户服务，而不必担心底层复杂的IT基础架构；
③可以迅速创建新的业务流程和复杂的应用程序，以适应市场变化；
④借助安全、易管理的集成环境，成为响应能力更强的IT组织；
⑤通过使用预装的、可重复使用的服务构建模块，缩短开发和部署周期；
⑥通过使用服务来降低复杂性和维护成本；
⑦是增强而不是替换现有的IT系统。

SOA的目标就是实现灵活可变的IT系统。要达到灵活性，通过三个途径来解决：标准化封装、复用、松耦合可编排。

SOA是一个不断解构的过程，传统软件强调系统性，耦合度过高，所以需要松耦合（解耦）；SOA也是一个组件粒度的平衡，集成电路趋势是集成度越来越高，软件发展的趋势是相反的过程；SOA是架构，更是方法，反映了人们对哲学思想的追求的原动力。

SOA的架构(Framework)
SOA的核心主体是服务。所谓“服务（Service）” ，从业务角度而言，服务是一个可重复的经过标准封装的任务，例如: 检查帐号余额;开新帐户 等等…。SOA的目标是通过服务的流程化来实现业务的灵活性，所谓流程（Process）是由一系列相互关联的任务所组成，实现一个具体的业务功能。一个流程可以由一系列服务来实现。

服务就像一堆“元器件”，这些元器件通过封装形成标准服务，他们有相同的接口和语义表达规则。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务、如何发现服务、如何包装服务的安全性和可靠性，这些就是SOA治理。SOA治理乃是将SOA这一堆元器件，进行有效组装，形成一个“产品”的关键，否则它永远是一堆器件，而无法形成一个有机整体。

由IBM提案，国际开放群组(The Open Group)提出了一个SOA架构的参考模型，这个架构框架目前是产业界最权威和严谨的SOA架构标准。The Open Group是一个非营利标准化组织，是一个厂商中立和技术中立的机构，致力于提出各种技术框架和理论结构，致力于促进全球市场的业务效率。
The Open Group已有超过20年的标准制定与推广历史。在1996年，由X/Open与Open Software Foundation合并组成。The Open Group最有名是作为UNIX商标的认证机构。在过去，协会最出名的是其出版的Single UNIX Specification，它扩充了POSIX标准而且是UNIX的官方定义，其成员包括IT用户、供应商以及政府机构。The Open Group在中国的创始会员为金蝶集团，金蝶集团负责成立了中国分会。TOG在1993年提出的The Open Group Architecture Framework (TOGAF) 架构框架，是一套行之有效的企业架构。历经15年9个版本发展，支持开放、标准的SOA参考架构，已被80％的福布斯( Forbes)全球排名前50的公司使用。这个SOA参考模型为：

根据这个模型，完整的SOA架构由五大部分组成，分别是：基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等。

SOA基础设施是为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑。

企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎，为SOA提供的软件架构的构造物。企业服务总线ESB提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。在SOA基础实现的方案上，应用的业务功能能够被发布、封装和提升（Promote）成为业务服务（Business Service）；业务服务的序列可以编排成为BPM的流程，而流程也可以被发布和提升为复合服务（Composited Service），业务服务还可以被外部的SOA系统再次编排和组合。ESB是实现SOA治理的重要支撑平台，是SOA解决方案的核心，从某种意义上说，如果没有ESB，就不能算作严格意义上的SOA。

关键服务实现，是SOA在各种业务服务组件的分类。一般来说，一个企业级的SOA架构通常包括：交互服务、流程服务、信息服务、伙伴服务、企业应用服务和接入服务。这些服务可能是一些服务组件，也可能是企业应用系统（如ERP）所暴露的服务接口等等。这些服务都可以接入ESB，进行集中统一管理。

开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，涵盖服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。

按照这个模型，许多SOA解决方案是只提供部分实现。真正按照SOA的思想和模型来构建整个企业的IT架构的案例是非常之少的。许多国外厂商的宣传案例，基本上是停留在部署应用服务器，开发了部分WebService组件，可以实现部分数据集成，这个层次而已，而这些WebService是部署在ESB平台之上的，就已经很不错了。实现了服务流程重组，实现SOA治理的案例就更是很少见到了。

架构方法论

许多企业的IT系统“孤岛”现象严重，本质上是缺乏足够有效的整体规划或者架构规划造成的。形象地说，构建企业IT大厦如同我们盖房子是一样的道理。我们许多企业建设信息系统时就采用了盖乡村民宅的做法。盖乡村民宅不需要严谨的规划，也没有复杂的地下设施建设（如自来水供水、排水、供气、地下停车场等），也没有需要建设污水处理、雨水收集等复杂的配套设施。而事实上，企业IT系统建设应该如城市建设，首先需要城市总体规划，然后根据功能区规划，设计和建设小区配套设施，“三通一平”实质就是构建建筑之间的公共基础设施，确保每栋建筑之间不是“孤岛”，然后每栋建筑还需详细的设计和工程施工。如果要消除信息孤岛，实现IT与业务的一致性，也需要有效的企业架构规划和设计。

SOA代表着一种面向服务的IT架构风格，SOA的技术本质和出发点，在于IT架构。而IT架构，是组织的企业架构的重要组成部分，它和组织的战略架构、业务架构一起，形成一个自上而下、紧密联系、相辅相成的有机整体。SOA代表着一种正在蓬勃兴起的革命性IT架构理念，和传统技术体系区别的关键特征之一就在于SOA是战略导向和业务驱动的。而国际和国内的各方面经验都告诉我们，对于一个组织而言，捕获战略、梳理业务和IT的最有效的措施就是架构。

企业架构(Enterprise Architecture，EA)，是从多个角度对组织的构件层次描述的规划蓝图，从各个层面反映组织的愿景、战略、业务、服务、人员、技术和产品及其相互之间的关系，辅以其管控和演进的规则。

一个企业架构内容包括业务架构（Business Architecture）、应用架构（Application Architecture）、信息架构（Information Architecture）、技术架构（Technology Architecture）等。

真正可以落地的SOA建设，必须且只能从架构出发。没有架构，"SOA"将变成一盘无法真正解决各种运营问题的技术和产品的大杂烩。优良的架构填补了业务需求与实际信息系统以及基础设施设计之间难以逾越的鸿沟。

基于服务的应用系统的本质特征是松耦合，以基本业务功能（服务封装）为系统的基本实现单元，然后通过服务编排（流程管理）来“组装”业务应用系统。相对于以往的应用系统，是面向技术组件，由系统程序实现业务流程，在复用、耦合方面都存在灵活性问题。

基于SOA的应用构建过程
服务建模是第一步，也就是服务识别和颗粒度确定。服务识别是方法论的第一步，服务识别的主要任务，是确定在一定范围内（通常是企业范围，或若干业务场景范围 内）可能成为服务的候选者列表，并确定服务的颗粒度，以及标识服务的接口。服务建模也就确定了应用系统架构的耦合程度。

服务封装阶段的主要任务是对服务进行规范性的描述，其中包括输入/输出消息等功能性属性，以及服务在业务层面的诸多属性。并决定服务以何种形式向外提供服务。服务可能是新开发的业务功能和业务对象的封装，也可能是遗留系统的服务封装，将遗留系统的软件资产以服务的形式进行封装，在新的架构上利用已有的资产。

服务治理就是将已经封装好的服务进行集中统一有效的管理。通过ESB基础设施，提供服务注册、存储、安全控制和版本管理等。服务注册阶段的主要任务是将服务注册到服务库。此时需要决定服务的命名、安全、性能、时间特性。

服务编排就是根据业务流程的需求，对服务进行组合和组装。服务组装是以实现业务流程为目的，通过对业务服务的组合和组装，实现更粗粒度的业务服务，实现最终的业务需求。

应用交付阶段主要任务是完成业务系统服务化组装和服务部署，实现业务按需交付。

基于SOA的应用系统是SOA架构的重要组成部分，也是SOA落地的地基。

SOA架构和微服务架构的区别

SOA和微服务架构一个层面的东西，而ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。

 1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

 2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

SOA架构特点：
1.系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】

2.系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

3.业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

4.微服务架构特点：
1.通过服务实现组件化
开发者不再需要协调其它服务部署对本服务的影响。

2.按业务能力来划分服务和开发团队
开发者可以自由选择开发技术，提供 API 服务

3.去中心化
每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

4.基础设施自动化（devops、自动化部署）的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。

公众号：jvm知识库