1.摘要

去年十月，我所在的公司组织了某部委工具中心项目的开发。该项目是以工具为单元对自动化运维工具集合进行管理的应用。工具中心为两级部署，一级工具中心作为其统一工具仓库，是各二级工具中心通用工具权威源，负责其通用工具的准入、全生命周期管理；二级工具中心为各省（市）工具仓库，存放来自一级工具中心的通用工具，负责各省（市）自建工具的准入、全生命周期管理，并作为工具最终运行平台，对外提供工具调用及监控服务。

在该项目中，我担任了架构师和项目负责人的职位，负责项目的架构评审、改造设计及实现。本文结合作者的实践，以工具中心为例，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该系统是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。经过项目组近一年的努力，本产品已顺利开发完成，目前已上线使用，取得客户和公司领导的一致好评。

2. 正文

近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式(Microservice Architecture Pattern)逐渐流行。它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通信协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。

微服务的基本思想在于考虑围绕着业务领域组件来创建应用， 这些就应用可独立地进行开发、 管理和加速。 在分散的组件中使用微服务云架构和平台使部署、 管理和服务功能交付变得更加简单。

微服务是利用组织的服务投资组合， 然后基于业务领域功能分解它们， 在看到服务投资组合之前， 它还是一个业务领域。

微服务这一概念出现于 2012 年， 是因软件作者 Martin Fowler 而流行， 他承认这并没有精确地定义出这一架构形式， 虽然围绕业务能力、 自 动化部署、 终端智能以及语言和数据的分散控制有一些常见的特性。

(1) 项目概述

随着某部委信息化进程的不断推进，对信息通信运行保障能力也提出了更高的要求。运维过程中通过借助于运维工具实现运维的自动化管理，由于当前在运的运维工具数量快速增长，各单位都有自己的运维工具，为了更好的利用好这些运维工具，建立统一的工具中心管理系统，管理和共享这些运维工具已经迫在眉睫。

为了解决上述问题，我们设计和开发了工具中心项目，该项目主要通过本地管理和共享管理等业务流程来实现全网自动化运维工具的管理：

1.本地管理负责省公司二级库这边工具的上传，发布审批，升级，部署，取消发布，删除等业务处理。

2.共享管理完成从省公司二级库把工具上传到总部一级库的过程，总部审批通过后共享给其他省分。

为了实现上述业务目标，完成业务功能，工具中心通过工具商店、在运工具和本地库管理三个微服务来实现。同时将项目团队划分为2个小组，根据功能的轻重缓急和工作量，安排各个微服务的研发。每个小组负责一个或多个组件完整的生命周期，最后各个服务组件通过RESTful HTTP协议进行服务组装。

（2）微服务架构的特点

传统的单块软件架构在构建部署和扩展伸缩方面有很大的局限性，传统的单块架构一般分为客户端用户界面、服务端应用程序和数据库三部分。系统中任何程序的改变都需要整个应用重新构建和部署新版本。另外传统的单块软件架构在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。而微服务架构可以完美的解决统一风格架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立，单一功能的改变只需要重新构建部署相应的服务即可。与单块架构相比，微服务架构有如下的特点：

1) 通过服务实现应用的组件化(Componentization Via Services)，在应用架构设计中，通过将整体应用切分成可独立部署及升级的微服务方式，进行组件化设计。

2) 围绕业务能力组织服务(Organized Around Business Capabilities)，微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大。

3) 基础设施自动化(Infrastructure Automation)，云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。

4) 故障处理设计(Design For Failure)，微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此微服务非常重视建立架构及业务相关指标的实时监控和日志机制。

5) 演进式的设计(Evolutionary Design)，微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。

（3）微服务架构应用

在本系统中，采用通讯层、业务逻辑层、基础平台层组成系统的微服务架构。

在微服务架构下，我们选择RESTful的进行通讯。每个微服务都统一对外提供REST服务。无论前端调用后端服务还是后端之间的服务调用都统一走RESTful，这样就统一了协议栈。微服务架构可以支持各种异构系统服务间的交互。

服务的注册与发现，服务之间需要创建一种服务发现机制，用于帮助服务之间互相感知彼此的存在。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。

负载均衡是服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务。我们主要支持随机、轮询、最少链接数的策略将来自网络的请求随机分配给内部中的多个服务器。

服务容错采用快速失败，失效切换的策略。如果连续失败多次则直接熔断，不再发起调用。这样可以避免一个服务异常拖垮所有依赖于他的服务。

（4）遇到的问题及解决方案

在微服务实践中，我们主要遇到三个问题，一运维开销及成本增加，因为每个微服务需独立运行，还可能采用多种语言环境，这将导致资源开销大；二代部分码重复，某些底层功能需要被多个服务所用；第三个问题是难以可视化及全面测试，在动态环境下服务间的交互会产生非常微妙的行为。因此，首先服务划分应尽量合理，不要划分太细太多，其次采用公共模块的方式提供底层服务，再次微服务可通过监控发现生产环境的异常，进而快速回滚，弥补可测性不足的问题。

通过项目实践证明，实施微服务架构收益会大于成本。在拥抱微服务之前，也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则，对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。