微服务架构综述——微服务的本质

       微服务的诞生是在互联网高速发展，技术日新月异变化以及传统架构无法适应快速变化等多种因素共同推动下的必然产物。

       随着越来越多的传统行业开始依赖互联网技术打造其核心竞争优势。如何从系统架构的角度出发，构建灵活、易扩展的系统，快速应对需求的变化；同时，随着用户量的增加，如何保证系统的可伸缩性、高可用性，成为系统架构面临的挑战。

       微服务的本质特征体现在如下几个方面（从整体架构的角度）：

1. 服务作为插件：传统实现组件的方式是隔离独立的部分或抽取公用的部分，构建共享库，从而达到解耦和复用的效果。共享库的变化意味着整个应用要被更新，并且需要被重新部署。如果应用由多个共享库组件组成，那么任何库的变更都将导致应用重新发布。而微服务架构的一个显著优势是，能以松散的服务方式，构建可独立化部署的模块化应用。当然，分布式调用会使效率降低，而且可靠性和稳定性也严重依赖于网络状况。

2. 围绕业务组织团队：提倡以业务为核心，按业务能力来组织团队，团队中的成员具有多样性的技能。

3. 关注产品而非项目：提倡产品模式构建，让团队负责整个服务的生命周期。这种模式可以较好避免项目模式中出现的，团队成员缺乏主人翁精神、难以制定有效的奖惩机制、团队成员缺乏产品成就感等问题。

4. 技术多样性：提倡针对不同的业务特征选择合适的技术方案，有针对性地解决具体的业务问题。对应单块架构系统，初始的技术选型严重限制其将来能否采用不同语言或框架的能力。微服务架构，使我们更容易在系统上尝试新的技术或解决方案。即使对一项新技术的尝试失败，也可以抛弃这个方案，并不会对整个产品带来风险。

5. 业务数据独立：传统的数据库大多是关系型数据库，存储的数据都是以结构化信息为主，但随着互联网的快速发展，数据的结构并不具有确定性，或者说结构发生变化的频率非常快，如何有效维护业务数据将成为迫待解决的问题。微服务架构提倡服务自主管理相关业务数据，有以下几个显著优势。

① 能够随着业务的发展，提供业务数据接口集成，而不是以数据库的方式和其它服务集成。

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

6. 基础设施自动化：微服务架构将应用程序本身分成多个小的服务，每个服务都是一个独立的部署单元。传统只需要部署一次就能上线的单块架构应用，采用微服务架构后，将需要对每个部分分别进行部署。这也意味着部署与运维的成本会随着服务的增多呈指数级增长。因此，微服务的实践将促使企业或者团队不断寻找更高效的方式完成基础设施的自动化以及DevOps（一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合）运维能力的提升。

7. 演进式架构：单一的技术平台已经无法适应市场的快速变化，组织应该随着业务的发展，随着企业的发展，不断尝试并改进架构设计，真正做到业务驱动架构，架构服务于业务。

相较于SOA的思想（对于复杂企业IT系统，应按照不同的、可重用的粒度划分，将功能相关的一组功能提供者组织在一起为消费者服务），两者间的区别如下：

SOA实现	微服务架构实现
企业级，自顶向下开展实施	团队级，自底向上开展实施
服务由多个子系统组成，粒度大	一个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构	无集中式总线，松散的服务架构
集成方式复杂（ESB/WS/SOAP）	集成方式简单（HTTP/REST/JSON）
单块架构系统，相互依赖，部署复杂	服务能独立部署

 

       虽说微服务有诸多优点，但在实施过程中需要对以下因素进行考量：

1. 分布式系统的复杂度

2. 运维成本

3. 部署自动化

4. DevOps与组织架构

5. 服务间依赖测试

6. 服务间依赖管理

       服务组件的响应性能，服务间协作的可靠性，异步通信机制对调试带来的困难，数据一致性问题等，都将出现在微服务架构的实施过程中。因此，在实施微服务前，我们需要清楚地了解它将带来的风险，从而使团队能找到更合适的方式来有效实施微服务。