企业平台及系统架构

1. 单体架构

1.1. 优点

易于开发：具备开发人员已经熟练使用的 IDE 或框架；
易于测试：使用已有的 UI 自动化测试工具进行端到端测试；
易于部署：打包整个应用到生产环境，并利用已有的自动化部署工具

1.2. 缺点

复杂性高
整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个 BUG 都会造成隐含的缺陷。
技术债务逐渐上升
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。
部署速度逐渐变慢
随着代码的增加，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更和缺陷修复，出错概率较高。
扩展能力受限，无法按需伸缩
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。
阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。由于单体架构的缺陷日益明显，所以越来越多的公司采用微服务架构解决上面提到的单体架构中的问题。

1.3. 实例

应用程序采用 Java web 应用，工程可以打包成一个 WAR 包，运行在 Web 容器 Tomcat 之上。WAR 包中包含前端实现用户交互界面（StoreFrontUI），订单服务、库存服务和邮寄服务通过不同的模块进行区分，但是整体是一个单体工程，只有一份代码库，共享一个数据库和数据结构；
单体服务结构简单，代码是一个统一的工程，容易开发、部署和维护。但是，正由于此，各个模块耦合严重，当工程大到一定程度后，会带来一系列的问题，某一个功能的单点故障会影响整个系统的正常运行。这就是一个典型的单体架构。

2. 面型服务架构(SOA)

2.1. 企业集成平台及技术

通信服务。提供分布环境下透明的同步/异步通信服务功能，使用户和应用程序无需关心具体的操作系统和应用程序所处的网络物理位置，而以透明的函数调用或对象服务方式完成它们所需的通信服务要求。
信息集成服务。为应用提供透明的信息访问服务，通过实现异种数据库系统之间的数据交换. 互操作. 分布数据管理和共享信息模型定义，使集成平台上运行的应用. 服务或客户端能够以一致的语义和接口实现对数据的访问与控制。
应用集成服务。通过高层应用编程接口来实现对相应应用程序的访问。这些接口以函数或对象服务的方式向平台的组件模型提供信息，用户无需对原有系统进行修改，只要在原有系统的基础上加上相应的访问接口就可以将现有的. 用不同技术实现的系统互联起来，通过为应用提供数据交换和访问操作，使各种不同的系统能够相互协作。
提供对二次开发的支持。集成平台需要提供一组帮助用户开发特定应用程序的支持工具，简化用户在企业集成平台实施过程中的开发工作。
平台运行管理。需要提供企业集成平台的运行管理和控制模块，负责企业集成平台系统的静态和动态配置. 集成平台应用运行管理和维护. 事件管理和出错管理等。通过命名服务. 目录服务. 平台的动态静态配置，以及其中的关键数据的定期备份等功能来维护整个服务平台的系统配置及稳定运行。

对架构的说明应包括从架构层面上如何支持业务流程编写与管理；如何向用户提供功能与信息服务；如何集成业务伙伴的功能；如何与底层数据库. 现有系统等进行交互，等等。在实现企业集成平台时所使用的关键技术包括：

数据交换格式。企业集成中常用的数据交换格式有：EDI. XML. STEP. PDML
分布式集成应用基础框架。主要的有CORBA. J2EE. Web Service
实现数据集成的常用模式。数据联邦. 数据复制和基于接口的数据集成
实现应用集成的常用模式。适配器集成. 信使集成. 面板集成. 代理集成模式

2.2. SOA架构概念

SOA 是 Service-Oriented Architecture 的英文缩写，就是面向服务的架构。面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（我们称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。面向服务的体系结构中的角色包括：
服务请求者：服务请求者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务请求者根据接口契约来执行服务。
服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自请求者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务请求者可以发现和访问该服务。
服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务请求者查找服务提供者接口。

2.3. SOA架构基本功能

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

SOA 基础设施是为整个 SOA 组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑。
企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于 XML 消息引擎，为 SOA 提供的软件架构的构造物。企业服务总线 ESB 提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。ESB 是实现 SOA 治理的重要支撑平台，是 SOA 解决方案的核心，从某种意义上说，如果没有 ESB，就不能算作严格意义上的 SOA。
关键服务实现，是 SOA 在各种业务服务组件的分类。一般来说，一个企业级的 SOA 架构通常包括：交互服务、流程服务、信息服务、伙伴服务、企业应用服务和接入服务。这些服务可能是一些服务组件，也可能是企业应用系统（如 ERP）所暴露的服务接口等等。这些服务都可以接入 ESB，进行集中统一管理。
开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，涵盖服务的设计、开发、配置、部署、监控、重构等完整的 SOA 项目开发生命周期。

2.4. SOA 架构的优势

SOA 可通过互联网服务器发布，从而突破企业内网的限制，实现与供应链上下游伙伴业务的紧密结合。通过 SOA 架构，企业可以与其业务伙伴直接建立新渠道，建立新伙伴的成本得以降低。
SOA 与平台无关，减少了业务应用实现的限制。要将企业的业务伙伴整合到企业的“大”业务系统中，对其业务伙伴具体采用什么技术没有限制。
SOA 具有低耦合性特点，业务伙伴对整个业务系统的影响较低。在企业与各业务伙伴关系不断发生变化的情况下，节省的费用会越来越多。
SOA 具有可按模块分阶段进行实施的优势。可以成功一步再做下一步，将实施对企业的冲击减少到最小。

2.5. SOA服务类别

面型服务架构(SOA)技术参考架构中包含的服务类别包括：

开发服务(Development Services)用于实现新开发的组件以及重用基础架构的能力。
业务创新优化服务(Business Innovation & Optimization Services)用于从IT和业务两个层面来监控和管理运行情况。
管理服务(Management Services)包括对服务. 应用和资源的管理和保护能力，如通过负载均衡来有效的分配系统计算资源

SOA解决方案中的很多服务都是由已有应用系统提供的，接入服务(Access Services)提供访问已有应用或遗留系统的能力，同时提供已有应用. 打包应用程序与ESB之间的桥接能力，将已有系统中的功能和信息转化为服务。

业务应用服务(Business App Services)指那些通过新的计算平台JavaEE来实现的新应用，它们所实现的功能和信息也都转化为服务提供出来。
　　在业务流程需要与外部的合作伙伴. 供应商交互的情况下，伙伴服务(Partner Services)提供文档. 协议以及伙伴管理的能力，比如说，可以提供企业边界处不同安全级别差异的转换。
信息服务(Information Services)是那些跟信息(而不是活动)有关系的服务，比如将多个系统中异构的数据，聚合. 转换为业务需要的统一整齐的业务数据对象来访问。信息服务通过联合. 复制和转换来解决基于不同实现方式的不同数据源之间的数据共享难题。
流程服务(Process Services)是指把多个服务聚合成为一个服务流程对应业务过程的服务，这种复合服务通常是长时间运行的过程。流程服务提供服务控制能力，将多个服务串起来实现一个业务流程。
交互服务(Interaction Service)一方面将人的活动，通过人机交互以服务的方式出现在整个业务过程中，作为流程服务)中的一部分;另一方面将IT的功能和数据传递给最终用户，并满足用户特定的使用习惯。

2.6. ESB企业服务总线

ESB是SOA架构中核心技术实现，是传统中间件技术与XML. Web服务等技术结合的产物，主要支持异构系统集成。ESB基于内容的路由和过滤，具备复杂数据的传输能力，并可以提供一系列的标准接口。ESB的主要功能：

服务位置透明性；
传输协议转换；
消息格式转换；
消息路由；
消息增强；
安全性；
监控与管理。

2.7. SOA 架构示例

某大型证券公司，随着业务系统的增加，迫切需要解决围绕业务系统间的数据和业务集成问题，并提升对接口的实时管控和治理。因此决定搭建一套基于企业总线 ESB 的 SOA 系统，通过 ESB 连接各个业务系统，实现基于系统接口间的数据交换和应用集成，为企业统一内部 IT 服务和数据集成，并提供核心业务能力输出，支撑与外部中小合作伙伴进行互联互通的能力。该项目的总体目标是期望从传统 IT 系统网状的结构，转变为基于总线型的 SOA 集成需求。在成功搭建了 ESB 服务总线和 SOA 管控和治理平台之后，该系统破除了“信息孤岛”，实现了以下改进和提升：
轻松实现了异构系统之间的业务协作，并增强信息系统的业务敏捷性，提升信息化管理水平
提高了服务交互和数据交换效率，杜绝了应用之间的点对点集成接口，有效降低应用系统与企业架构的集成时间，实现实时的服务集成和数据交换。
增加了系统可靠性，减少了企业应用系统的维护工作，减轻对人员能力的需求，差错几率最小化，提高了稳定性和可用性。
整理形成一整套的服务管控和治理规范，服务识别和开发流程，对新系统的接入和新服务的开发提供完整支撑。

3. 微服务架构

3.1. 微服务架构的概念

微服务架构风格的开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用 HTTP资源 API 轻量的机制来相互通信。
这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
对于整体式架构来说，整体式应用将所有功能放到一个进程中，然后通过复制整个应用到多台服务器实现扩展。
对于微服务架构来说，微服务架构将功能的每个元素放置到分离的多个服务进程中，通过将不同服务分布于不同的服务器，并按需复制服务的方式实现扩展。

3.2. 特性

每个微服务可独立运行在自己的进程里；
一系列独立运行的微服务共同构建起整个系统；
每个服务为独立的业务开发，一个微服务只关注某个特定的功能，如订单管理、用户管理等；
微服务之间通过一些轻量的通信机制进行通信，如 REST API 接口进行调用；
可以使用不同的语言与存储技术；
全自动的部署机制。

3.3. 微服务架构的优势

易于开发和维护
- 一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态；
单个微服务启动较快
- 单个微服务代码量较少，所以启动会比较快；
局部修改容易部署
- 单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；
技术栈不受限
- 在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈。
按需伸缩
- 可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存、升级 CPU 或者增加节点。

3.4. 微服务架构的挑战

运维要求较高
- 更多的服务意味着更多的运维投入。在单体架构中只需要保证一个应用的正常运行；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，带来了巨大的挑战；
分布式固有的复杂性
- 使用微服务构建的是分布式系统。对于一个分布式系统来说，系统容错、网络延迟、分布式事务等都带来了巨大的挑战；
接口调整成本高
- 微服务之间通过接口进行通信。如果修改某个微服务的 API，可能所有使用了该接口的微服务都需要做调整；
重复劳动
- 很多服务可能都会使用到相同的功能。而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，导致代码重复。

3.5. 微服务架构示例

我们在单体架构中讲到了一个采用单体架构设计和开发的电子商务网站，当这个网站的业务逐渐扩展、规模逐渐扩大的时候，单体架构会有很多的问题和缺陷。那么，同样一个电子商务网站，如果我们使用微服务架构来设计它，应该是什么样子的呢？如图所示。这个电子商务网站，也需要接收来自客户的订单，验证商品库存，并邮寄商品。

采用微服务之后，单体工程被拆分成多个独立的服务，进行独立开发和部署，拆分为前端服务、订单服务、库存服务和邮寄服务。这些服务在独立的进程中运行，相互之间通过 API 进行通信。
当某一个服务出了问题也不会影响别的服务，例如，物流系统出了问题但不影响客户的订单支付。各个服务可以由完全不同的团队分别进行维护，适用于比较复杂的工程

3.6. 微服务架构与 SOA 架构的区别和联系

3.6.1. 区别

SOA 架构注重重用，微服务架构注重重写
SOA 的主要目的是为了企业各个系统更加容易地融合在一起。微服务通常由重写一个模块开始。要把整个单体应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始。把它们一个一个剥离出来用敏捷的方式重写，可以尝试最新的技术和语言和框架。
SOA 架构注重水平服务，微服务架构注重垂直服务
SOA 设计喜欢给服务分层。例如，把数据访问层设计为一个实体服务层。这种设计要求所有的服务都通过这个实体服务层来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的数据库。在微服务中，拆分数据库时可以适当的做些改变，让它不需要依赖其他服务的数据。
SOA 架构注重自上而下，微服务架构注重自下而上
SOA 架构在设计开始时会先定义好服务合同。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，原理图等。SOA 架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口。微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来，然后快速确认业务需求，快速开发迭代。

3.6.2. 联系

微服务与 SOA 有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与 SOA 原则的演化的目标也是相同的，即减少传统的企业服务总线开发的高复杂性。但是两
种架构背后的意图是不同的：

SOA 尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。
微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。
所以对于我们去选择服务技术框架时，应该针对 SOA、微服务两种架构进行设计，同时要考虑到兼容性，阶段性选择适合的架构。