李忠民+++齐占新
摘 要：微服务架构已经在实践中被普遍应用，国网也在努力实践“一平台一系统多场景微应用”的设计理念，但是在微服务架构的实施过程中，作者感觉业界在微服务架构论述上把业务架构和技术架构糅合在一起，概念不是很清晰；同时在实践过程中作者对微服务的粒度划分标准有自己一些认识，文章围绕上述两点展开讨论，谈谈自己的观点。
关键词：微服务架构；微应用化；微服务化；微服务粒度
每个新的技术概念的提出都是为了解决应用实践中面临的问题，同时新的技术概念往往引起应用实践模式的转变，这一点在架构设计领域表现的尤为突出。二者有点像经济基础和上层建筑的关系，经济基础决定上层建筑，上层建筑反过来又显著地影响着经济基础；同样，业务架构决定技术架构，技术架构反过来又显著影响着业务架构，微服务架构的提出和实施，不可避免会要求业务架构做出相应演进。
作者从国网“一平台一系统多场景微应用”的实施过程中，逐渐认识到微服务架构的实施实际上分为如下两个部分：业务架构的微应用化；技术架构的微服务化。
下面首先提出微应用、微服务的概念，从而引出业务架构的微应用化和技术架构的微服务化观点。
1 微服务架构
总结微服务架构的提出者Martin对微服务架构的定义，微服务架构有如下特征：由多个分布式服务组成，多个独立的服务，共同组成系统；每个服务单独部署，运行在独立的进程（容器）里；服务可以独立设计、开发、部署，可以采用不同的技术路线；分布式的管理。
微服务架构模式有许多优点：拆分单一的復杂性的单体应用为可管理的模块或服务。单个的服务可以更快的开发，更简单的理解和维护。每个服务可以由单独的团队独立开发，开发者可以自由地选择合理的技术，只要服务遵守 API 约定即可。每一个微服务能被独立部署，让持续部署成为可能。
可见微服务架构是一个技术概念，是从技术架构角度来提出的一种新架构模式，是一种新的设计、开发、实施、运维的实践方法，从企业架构（EA）角度分析，应该划分到技术架构的范畴。
2 微服务
微服务是一个高内聚低耦合IT的实体，有明确的边界，属于技术架构的范畴，可独立设计、开发、测试、部署、运维管理，一般具有自己的表现层、业务层甚至数据库层，一般每个服务实例运行在一个容器中。
3 微应用
微应用是一个高内聚低耦合的业务实体，有明确的业务边界，微应用应该是一个完整的、自洽的业务模块，属于业务架构的范畴。
微应用是从应用场景中抽象总结出来的一些独立业务模块，模块之间很少相互的业务联系，即使有也通过工作流等机制进行。
从领域模型的角度来看，微应用应该是居于业务对象和聚合体之上的一个概念，也就是说其粒度要比聚合体更加粗一些，比业务用例也更加粗一些，是相对独立的一个业务模块。
从用户角度看微应用能够提供用户要求的某一组服务，为企业创造一个明确的经营价值，达成用户的一个某个在经营层面可见的目标。
而作为对照，业务用例一般完成某个特定的功能，比如下单、客户资料修改等，由于粒度过小不能提供一个经营层面可见的价值。
4 微应用和微服务的关系
微应用和微服务都是相对独立的单元，都具有高内聚低耦合的特征，都有一个明确的边界。但是二者是不同领域中的概念，从本质上来说是两个独立的概念。
微应用是一个业务概念，是有独立功能，能够满足用户一个完整业务需求的功能，能够实现一个经营层面可见的目标。微服务是一个IT实体，是能够独立开发、测试、部署、运行的模块，一般依托容器运行。
微应用和微服务没有一一对应的关系，有一个比较贴切的比喻：二者之间的关系就像领域模型中的业务实体和java对象之间的关系。往往一个微服务实现了几个微应用，也存在一个微应用跨越几个微服务的情景。
5 微应用和微服务的划分标准
引入微服务架构的初衷是降低系统开发和实施过程中的复杂性，使得过程可控，因此从实用主义的角度，从系统生命周期中与系统关系最密切的几类人员，即分析人员、设计人员、开发人员、运维人员角度来说明微应用和微服务的划分原则，是比较有实用价值的。此种划分方式比纯粹学术上的研究要有指导意义的多，举例来说业界曾有观点：微服务应该细化到每个菜单作为一个微服务的程度，这个观点明显是脱离实际，为微而微，望文生义，极大地增加了运维成本和管理成本，是非常教条的。
下面按照以上原则说明微应用和微服务的划分标准
5.1 微应用的粒度
微应用是处于子系统和业务用例之间的一个模块级别，其虽然名称中有“微”，但是不能过于小，否则徒增复杂性，对于架构的优化改进没有任何助力。
可以把能否提供一个“企业经营管理层面可见的价值”作为识别微应用的主要标准。同样是对业务进行模块划分，具体经办的业务人员和经营管理人员的视角不同，粒度不同，业务人员从“做什么”入手，因此他们划分出的单元往往是业务用例级别的，而经营管理人员往往从“有什么用”角度入手，他们划分出的业务模块往往是粒度比业务用例稍大。
视角的不同，引起划分标准和划分结果的不同，前文已经说了，微应用应该是比业务用例稍大的粒度，以经营管理者的视角对业务进行划分，是微应用的比较合理的划分方法。
识别什么是微应用，还与应用系统的设计目标和定位有关，比如同样是人力资源管理系统，如果系统的重点在于员工档案管理，则员工培训业务可以看做一个微应用，但是对于以培训为重心的人资系统，则把培训业务分解为多个微应用更加合适。
5.2 微服务的粒度
划分微服务的标准则有如下几点：
从设计角度：微服务应该是高内聚低耦合的，有明晰的界面，与外界尽量少的交互。
从开发角度，微服务应该是一个小的团队、在短时间内可以完成的，保持沟通的高效和管理的低成本。
从运维的角度：微服务的粒度不能太小，种类不能太多，否则会使得系统复杂性和管理成本急剧上升，有违微服务架构的初衷。
6 业务架构的微应用化和技术架构的微服务化
按照架构设计的有关实践，系统架构分为业务架构、应用架构、技术架构、数据架构、安全架构等几部分。
如前文所述，微应用是属于业务架构范畴的概念，微服务是属于技术架构范畴的概念。故在微服务架构的实施过程中，实际上存在业务架构的微应用化和技术架构的微服务化两个方面的工作，而业界往往把二者混淆。
6.1 业务架构的微应用化
首先利用傳统的分析方法对企业全局范围内的业务进行梳理，开发业务架构，然后再进行重构与整合，对业务进行拆分，从中识别出微应用，达到业务架构的微应用化。
微应用化的主要工作是产生微应用清单，定义微应用的业务功能和业务边界，规范跨越两个或者多个微应用的业务，对于跨微应用的业务尽量利用工作流等机制实现衔接，从业务层面避免技术实现时的分布式事务产生的可能性，降低实现和实施的复杂性。
6.2 技术架构的微服务化
微服务化的根本原则就是降低设计、开发、测试、实施、运维过程中的复杂性和成本，在微服务化实施过程中会遇到很多问题，其中最具争议的就是微服务的粒度问题，只要遵循这个基本原则，则尺度就比较好把握。
微服务化架构的实施涉及到设计、开发、部署、运维等各个方面。
6.2.1 设计过程
微服务可以分为两类：应用层微服务：实现了业务逻辑，可以认为这部分微服务是微应用的实现，但没有必要和微应用一一对应。
基础层微服务：实现了公共设施和公共模块。
设计过程是在业务微应用化的基础上展开的，但是微应用和微服务不必要一一对应，微服务的设计过程就是需要对业务进行拆分和分层：拆分：参照微应用进行拆分，构建应用层微服务集群。分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层。
当然设计过程中还要解决很多其他问题，如服务注册、服务注册、服务间通讯机制等问题。
6.2.2 开发过程
开发过程中首要原则就是接口先行，面向接口编程，首先需要把接口识别和定义出来，然后双方基于接口进行开发，合理控制团队规模和开发周期，降低管理成本，提升产能。
6.2.3 部署过程
部署过程要利用工具进行自动化部署。
部署原则：容器化、独立部署、基础设施自动化。
6.2.4 运维过程
运维过程要充分利用工具实现自动化运维。
