转载

数字化转型｜企业IT应用的架构发展历程

应用架构（Application Architecture）描述了IT系统功能和技术实现的内容。应用架构可简单分为以下两个不同的层次：

企业级的应用架构：企业层面的应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。在企业架构中，应用架构是最重要和工作量最大的部分，他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

单个系统的应用架构：在开发或设计单一IT系统时，设计系统的主要模块和功能点，系统技术实现是从前端展示到业务处理逻辑，到后台数据是如何架构的。这方面的工作一般属于项目组，而不是企业架构的范畴，不过各个系统的架构设计需要遵循企业总体应用架构原则。

一、系统应用架构

1、Web为B/S结构（浏览器/服务器即Browser/Server，简称 B/S），比如：Web网站和WebAPP。只有一个版本，服务端和Web端更新了之后，刷新一下页面也就同步更新了；

2、PC、APP为C/S结构（客户机/服务器即Client/Server，简称C/S），比如：Native APP（原生）和Hybrid APP（混合）。服务端更新了，需要对各个主流版本进行兼容测试及回归测试，客户端更新的话，还需要重新安装或升级应用。

二、系统应用架构演进历史

软件架构发展历程，从单体架构，到垂直架构、SOA 架构、微服务架构。

1、单体应用架构（ORM）

数字化转型｜企业IT应用的架构发展历程

单体架构特点：

（1）所有的功能集成在一个项目工程中

（2）所有的功能打一个war包部署到Docker或服务器

（3）应用与数据库分开部署

（4）通过部署应用集群和数据库集群来提高系统的性能

单体架构优点：

项目架构简单，前期开发成本低，周期短，小型项目的首选。

单体架构缺点：

（1）全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护

（2）系统性能扩展只能通过扩展集群结点，成本高、有瓶颈

（3）技术栈受限

2、垂直应用架构（Modle View Controller，简称MVC）

当业务规模很小时，将所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流；此时，用于分离前后台逻辑的 MVC 架构是关键。

数字化转型｜企业IT应用的架构发展历程

垂直架构特点：

（1）以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。

（2）项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。

（3）项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

垂直架构优点：

（1）项目架构简单，前期开发成本低，周期短，小型项目的首选。

（2）通过垂直拆分，原来的单体项目不至于无限扩大。

（3）不同的项目可采用不同的技术。

垂直架构缺点：

（1）全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

（2）系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3、面向服务架构（Service Oriented Architecture，简称SOA）

当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分是关键，服务数量也会越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的 SOA 服务治理是关键。

数字化转型｜企业IT应用的架构发展历程

（1）企业服务总线（Enterprise Service Bus，简称ESB）

ESB概念是从面向服务体系架构(Service Oriented Architecture， SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型；其中的软构件集是以一种定义清晰的层次化结构相互耦合。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。

在企业计算领域，企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。

企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。

ESB是将所有的系统的交互都放在SOA统一服务总线上面来控制处理，技术人员可以开发符合ESB标准的组件（适配器）将外部应用连接至服务总线。

（2 ）WebService的常用的方法

A、远程过程调用协议（Remote Procedure Call，简称RPC），面向方法

RPC是一种允许分布式应用程序调用网络上不同计算机的可用服务的机制。比如从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。

下面简单介绍几种典型的RPC远程调用框架：

（a）RMI实现，利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol)和java的原生序列化

（b）Hessian，是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。基于HTTP协议，采用二进制编解码

（c）thrift是一种可伸缩的跨语言服务的软件框架。thrift允许你定义一个描述文件，描述数据类型和服务接口。依据该文件，编译器方便地生成RPC客户端和服务器通信代码

（d）dubbo，阿里的RPC框架

（e）还有SpringCloud框架，微服务全家桶。为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等

B、简单对象访问协议（Simple Object Access Protocol，简称SOAP），面向消息

简单对象访问协议是一种数据交换协议规范，是一种轻量的、简单的、基于XML的协议的规范。SOAP协议和HTTP协议一样，都是底层的通信协议，只是请求包的格式不同而已，SOAP包是XML格式的。

SOAP的消息是基于xml并封装成了符合http协议，因此，它符合任何路由器、防火墙或代理服务器的要求。

C、表象化状态转变（Representational State Transfer，简称REST），面向资源

采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。

RESTful是一种架构设计风格，提供了设计原则和约束条件，而不是架构，而满足这些约束条件和原则的应用程序或设计就是 Restful架构或服务。RESTful的核心就是后端将资源发布为URI，前端通过URI访问资源，并通过HTTP动词表示要对资源进行的操作。

D、REST、SOAP和RPC之间的区别

（a）在SOAP模式把HTTP作为一种通信协议，而不是应用协议。所以http中的表头，错误信息等全部无视。实际上http有 put get post delete等方法；REST 则不然，HTTP method中的 POST GET PUT DELETE 都是与请求方法对应的，rest真正实现了http的五层结构

（b）REST是一种轻量级的Web Service架构风格，其实现和操作比SOAP和RPC更为简洁

（c）SOAP可以使用任何语言来完成，只要发送正确的soap请求即可，基于soap的服务可以在任何平台无需修改即可正常使用

（d）RPC 风格的 Web Service 跨语言性不佳

（e）总结建议

成熟度上：SOAP在成熟度上优于REST；

效率和易用性上：REST更胜一筹；

安全性上：SOAP安全性高于REST，因为REST更关注的是效率和性能问题；

总体上，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的Web服务开始采用REST风格设计和实现。

面向服务架构特点：

（1）基于SOA的架构思想将重复、公用的功能抽取为组件，以服务的方式给各个系统提供服务。

（2）各个项目（系统）与服务之间采用webservice、rpc等方式进行通信。

（3）ESB企业服务总线作为项目与服务之间通信的桥梁。