微服务架构综述

一、三层架构模式

一直以来，系统的架构设计是IT领域经久不衰的话题之一，是每个系统构建过程中及其关键的一部分，它决定了系统是否能够被正确、有效地构建。

随着面向对象分析、设计模式、企业架构模式等方法论的深入人心，从功能实现、代码组织的角度考虑，系统中不同职责的部分逐渐被划分到了如下三个层次：

1、表示层，聚焦数据显示和用户交互

2、业务逻辑层，聚焦业务逻辑处理

3、数据访问层，聚焦数据的存储与访问

三层架构的出现，解决了系统间调用复杂、职责不清的问题，也有效降低了层与层之间的依赖关系，成为软件架构的经典模式之一。虽然三层架构在逻辑分成了三层，但它并不是物理上的分层。也就是说，对不同层的代码而言，经历编译、打包、部署后，所有的代码最终还是运行在同一个进程中。对于这种功能集中、代码中心化、一个发布包、部署后运行在同一个进程中的应用程序，我们通常称之为单块架构应用。

随着业务的不断扩大，需求功能的持续增加，单块架构已经很难满足业务快速变化的需要。一方面，代码的可维护性、扩展性、灵活性在降低；另一方面，系统的修改成本、构建以及维护成本在显著增加。因此，单块架构应用的改造与重构势在必行。

二、微服务模式

1、从业界的讨论来看，微服务本身并没有一个严格的定义。不过，马丁·富勒先生，对微服务的这段描述，比较通俗易懂：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立的地部署到生产环境等。另外，应根据业务上下文，选择合适的语言、工具对其进行构建。

2、微服务的本质

所谓本质特征，就是当我们谈论同一件事情的时候，不同的人们所关注的相同的部分。从业界的讨论来看，微服务的本质特征通常包括如下几个部分：

-服务作为组件

微服务也可以被认为是一种组件，但与传统组件最大的区别是，微服务可以被独立部署。

-围绕业务组织团队

以业务为核心，按业务能力来组织团队，团队中的成员有多样性的技能

-关注产品而非项目

倾向于让团队负责整个服务的生命周期，从服务的分析、开发、测试、部署、运维。

-技术多样性

问题有其具体性，解决方案也应有其针对性。在微服务架构中，提倡针对不同的业务特征选择适合的技术方案，有针对性地解决具体的业务问题。

-业务数据独立

微服务架构，提倡服务自主管理其相关的业务数据。这样存在几个非常明显的优势：

（1）能够随着业务的发展，提供业务数据接口集成，而不是以数据库的方式同其他服务集成。

（2）能够随着业务的发展，选择更合适的工具管理或者迁移业务数据。

-基础设施自动化

微服务架构将应用程序本身分成多个小的服务，每个服务都是一个独立的部署单元。因此，采用微服务架构后，将需要对每个部分分别进行部署。另外，每个服务都需要部署带来的健康监控、错误回滚、日志分析等，成本也会显著增加。换句话说，部署与运维的成本会随着服务的增多呈指数级增长。因此，在微服务的实践过程中，对持续交付和部署流水线的要求较高，需要稳定的基础设置自动化机制，能够创建运行环境，安装依赖，部署应用等。

-演进式架构

微服务架构将一个复杂应用拆分成多个服务，每个服务都是一个独立的、可部署的业务单元。同时，每个服务都能独立运行在独立的进程中，并且服务之间通过轻量级的通信机制建立联系。从某种程度上而言，这些特点保证了在应用软件随着业务发展而不断变化的过程中，企业或者组织能够不断调整软件的架构，将不需要的服务（业务）抛弃，将需要的服务（业务）升级，并采用合适的技术或者工具不断优化架构，保持其处于一个不断演进的状态。