作者：张允君，卫洁，付小攀，彭霄
（远光软件股份有限公司）
0 引言
随着信息化的发展，信息化建设对于企业发展与经营管理起到了明显积极正向的作用与促进，企业对信息化也提出了更高的要求，诸如：快速响应业务需求，IT 架构弹性扩展、系统应用场景化等。
IT 业界各大公司及资深专家都在探索研究相应的解决思路与配套方案。2012 年5 月Martin fowler发文首提微服务架构概念，指出微服务是一个架构风格与设计理念，可以是一种企业信息化架构模式，也可以是一个信息系统的架构模式。一个大型应用由一套微服务组成，系统中的每个微服务可被独立部署，每个微服务之间是松耦合的，并以轻量级机制进行通信。每个微服务仅关注于完成一件任务，代表某个场景的业务能力。一个服务能够被其团队在2 周之内重写，这样规模的服务可称为微服务，以便满足敏捷、快速交付的需要。
微服务架构理念首先被国外企业应用，如Amazon、eBay 等。近2 年，国内一些创新企业开始尝试采用微服务架构替换传统IT 架构（SOA 架构）。伴随微服务架构应用的逐步深入，与微服务相当的一个概念“微应用”应运而生，但目前尚未有权威机构对此概念进行定义。
基于微服务架构等理念，结合应用实践，微应用是指采用微服务架构理念的一种软件形式。具备以下关键特征：由一组后台微服务及前端应用界面组合而成；具有交互界面可以直接面向终端用户；以领域驱动设计（Domain-Driven Design，DDD）为指导思想进行设计；可以按需灵活组合后端微服务以满足多场景业务需求。
1 国内外微服务架构研究应用概况
1.1 业界关注热度分析
近几年，微服务受业界关注的热度持续攀升（见图1、2）。
图1 和图2 首先体现了微服务概念受的关注度在持续稳步提升；其次，从一定程度上说明微服务架构理念也正在被更为广泛地认可；最后，从一定程度上说明受信息化发展需求地驱动，微服务架构已经被较为广泛地认为是一种潜在解决方案或思路。
1.2 部分企业研究概况
据不完全统计，目前国内外已有较多企业在开展或已实现微应用/ 微服务架构的研究、实施、落地应用工作。互联网类公司在信息化架构方面步伐较快，起到了预研究、探索、引领的作用。信息化应用方与提供方都在向微服务架构方向行进。部分有代表性的公司/ 企业分析如下。
1）eBay。eBay 公司自1995 年起经历数代信息化架构演进，从单体架构演进至SOA 架构，历时3 年于2014 年完成了从SOA 架构向微服务架构的演进。
2）Amazon。Amazon 公司自1995 年起经历多轮信息化规划、改造、整合、融合及架构演进。大体是从单体架构演进至SOA 架构、SOA 架构融合单体架构、SOA 架构改造优化（云化等），历时3 年于2014 年完成大部分核心应用系统的微应用化，并正在开展全面微服务架构化的演进工作。
3）阿里巴巴。阿里巴巴公司自1999 年起，信息化建设从无到有，完成多轮信息化规划、建设、整合、融合及架构演进。大体是从单一网站到单体架构，从单体架构到SOA 架构，从SOA 架构到混合架构，从混合架构经历规划、整合、融合到SOA 架构，从SOA 架构向微服务架构演进，目前正处于SOA 架构与微服务架构的混合架构中，并正在开展全面微服务架构化的演进工作。
4）远光软件股份有限公司。远光软件股份有限公司自1998 年成立，致力于电力行业集团资源管理软件研发供应，经历了企业本身以及所服务大客户的多轮信息化架构演进，并于2013 年起研究微服务架构，目前正在开展全面以“微服务+ 云平台”为整体理念的企业微服务架构演进工作。
5）国家电网公司。国家电网公司自成立起，经过多年信息化建设，完成多轮信息化规划、建设、整合、融合及架构演进。2006 年起，历经SG186、SGERP、集中部署等工程建设，充分引入SOA 架构理念，已实现“纵向贯通、横向集成”。目前正在开展微服务架构的研究与实践尝试工作。
2 特定企业部分特征
并非所有的企业都适合采用微服务架构理念开展信息化建设工作，并非所有的企业在微服务架构落地过程中的思路、方法、关注点都完全相同，同时，微服务架构理念并非适用于所有应用场景。本文相关结论与建议适用于具有以下特征的相关企业。
2.1 企业组织特征
1）集团性质企业。表现为以总部为核心、多层次的组织结构；在内部的管理体制上，表现为企业集团中各成员企业，既保持相对独立的地位，又实行统一领导和分层管理的制度，建立了集权与分权相结合的领导体制。
2）金字塔型集团。金字塔型结构又称持股型结构，是标准的产权控制模式；意味着上层组织对下层单位有强管控能力，采用强管控的模式进行经营管理。
3）具备一定研发实力。企业内部具有一定的研发实力，可以独立完成或借助外力完成信息化软件的需求、设计、研发、运维。
2.2 信息化相关特征
1）信息化应用程度深。企业已经开展了较长时间（3 年及以上）的信息化建设、运维工作，企业内部当前的信息化架构为SOA 或带有SOA 架构的混合架构。
2）信息化应用场景多。从岗位角色覆盖面而言，企业内部的大部分岗位或角色都有需要通过信息化手段完成的经营、管理的需求或要求。从信息化层次结构而言，应用场景涵盖实施操作层、经营管理层、战略决策层等多个层面。
3）信息化需求变动频繁。受各类因素驱动，信息化相关业务需求变动频繁，且希望信息化变动需求能够在较短（以周为单位）时间内得到响应与落地应用。
3 远光软件应用微化实践
在确定了采用微服务架构方案后，从传统架构演进至微服务架构是一个系统工程。结合远光软件股份有限公司的实践过程进行分析，应用微化实践过程中的推进思路与实践步骤。
3.1 微应用生态圈的组成
落地微服务架构，首先要认识到微应用实际上是一个生态圈，生态圈中包含的关键主体有：微应用平台、核心开发团队、平台运维团队、核心应用者、微应用消费者、平台运营团队（见图3）。
1）微应用平台是指用于微应用产品全生命周期的集设计、开发、集成、运维、运营于一体的综合性平台；是将康威法则、领域驱动设计、分而治之、KISS原则等方法论/ 指导思想充分融入的平台类开放型产品，是微应用生态圈的核心。
2）核心开发团队主要负责微应用平台的需求、设计、研发、应用、协助运维等主要工作，达到产品功能与非功能方面的螺旋上升的目的。微应用平台本身不输出直接面向终端消费者的具体微应用产品。
3）平台运维团队主要负责平台的消缺，更为重要的是分析缺陷提出优化整改意见，并跟进落实产品的优化整改情况。
4）核心应用者主要负责基于微应用平台进行平台的微应用产品研发，输出微应用产品；可以是个体、团队、产品研发商，他们是微应用平台的二次加工方，基于平台加工出可以面向终端消费者的具体微应用产品。
5）微应用消费者是微应用产品的消费方，消费具体的微应用产品，直接或间接参与微应用产品或微应用平台的优化改进。
6）平台运营团队主要负责平台的宣传、推广、培训及应用情况分析；协助平台需求收集，润滑生态链中的各个环节，推进平台的完善与提升，保障平台的整体生态运作积极向上。
3.2 微服务架构的统一认识
微服务架构落地是一个系统工程，参与这个工程的人员必然不少，本例中据不完全统计（未统计微应用消费者数量）参与人员多达700 余人，其中包含工程决策链10 余人、核心开发团队100 余人、平台应用者500 余人、平台经营团队60 余人、平台维护团队40 余人。
统一工程参与各方的认识与思想也就成为这个工程能否顺利推进最后成功落地的前提。统一认识过程中主要有以下几部分需要重点关注。
1）工程决策链，认可重视。对于软件供应商而言，拟开展微服务架构落地工程，向工程决策链上的各级干系人说明工程的必要性、意义、推进思路、预期成效等事项的重要性。需要达到决策链各级干系人认可此工程项目并重视项目的推进进展的目的。
2）平台研发方，认识统一。平台研发方（主要包括：核心开发团队、平台运营团队、平台运维团队）是工程项目的主体核心输出物——微应用平台的产出方。平台类产品的非功能性要求要高于一般产品，需要具有相对更高的产品意识进行产品的研发、经营、维护。需统一此部分人员的认识，以保障核心输出物的严标准、高质量的目标。
3）核心应用者，宣贯统一。核心应用者是具体微应用的缔造者，是面向终端用户的产品研发方。除了传统的产品意识外，基于微应用平台的研发，还需要做到以下几方面的意识统一。主要包括：基于现有微应用平台实现、遵从统一技术路线、遵守相关开发规范、秉持“微”理念（即：基于特定角色、特定场景的应用，同时业务上要保障一个业务场景的完整性）、积极参与平台的优化完善。
4）应用消费者，宣贯认可。应用消费者是微应用产品的终端，产品应用前后有大量的宣贯工作需要开展以达到消费者认可愿意为其买单的目的。产品应用前，需要说服消费者尝试新模式、新产品，打动消费者，最终接受微服务架构下的微应用产品。产品应用后，需要做到让消费者切实感受到与以往不同的产品应用体验，达到并愿意代为宣传推荐的目标。
3.3 微应用平台的构建
微应用平台是微应用生态圈的核心，微应用平台健壮与否、功能完备与否很大程度上决定了项目是否烂尾。本案中微应用平台架构如图4 所示。
3.3.1 开发运维中心
DevOps（Development 和Operations 的组合）是一组过程、方法与系统的统称，用于促进开发、技术运维和质量保障部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。平台应用者、平台运维团队可以基于此模块进行快速、高效的协作，最终实现需求的快速响应与交付。
3.3.2 微应用运行中心
将微服务打包成独立部署的载体，这个载体可以部署在常规的服务器或虚拟化资源或一体机之上，实现计算能力的水平拓展和微应用间数据的隔离。其中封装了Web 应用服务器、服务注册发现、轻量级RPC 和服务调用的负载均衡策略等功能组件。微应用由内嵌的Web 容器统一管理生命周期，提供应用部署、日志管理等组件，支持在运行时动态调整参数以提高JVM 性能。可以通过微应用中心轻松实现微应用程序的嵌入，开发者可以直接将容器的操作包含在程序逻辑中，而不需要应用程序做出任何修改。传统架构模式下是将应用部署在容器中，而微应用是将容器嵌入到应用中。
其中，API 网关主要负责封装内部系统的架构，并且提供API 给各个客户端；负责请求转发、合成和协议转换；授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等工作。微应用与微服务是指具体的可以响应终端用户的业务请求的应用程序或后台服务。基础服务主要是指微应用平台本身正常运行所依赖或提升管理能力的底层服务，如熔断与降级管理服务、注册与发现服务、通信与安全服务、监控服务等。运监自动化主要是用于与开发运维中心、微应用运营中心间通信联动的组件。
3.3.3 微应用运营中心
微应用运营中心主要负责微应用产品的运营相关工作，主要包括微应用商店、API 商店、微应用生态管理3 部分。微应用商店界面示意如图5 所示。
1）微应用商店作为微应用的分发入口，供用户便捷预览、选择、安装和使用微应用，同时管理微应用的全生命周期，包括微应用的上架、审核、统计、下架等功能。
2）API 商店为企业应用提供标准的访问接口，对各种服务接口进行统一管理。在平台底层整合了各种基础服务，实现了统一的API 访问机制。API商店实现对API 接口的发布、注册、查询、调试、授权、统计、分析等一系列精细化管理。
3）微应用生态管理主要是实现对具体微应用的应用情况进行统计分析以辅助其生命周期的决策管理。具体监控指标包括：评价情况、日活量、更新维护情况等。
指导思想与方法论：是指需要融入到平台基因与血液里的理念，主要包括康威法则、领域驱动设计、分而治之、KISS 原则等。对于不同的企业，指导思想与方法论不一定完全相同。分析企业中当前在哪些方面处于短板，并进行强化应用。
3.4 微应用平台的应用
在实际项目推进过程中，微应用平台的应用是项目成功与否的关键所在。对于平台的应用应重点关注以下3 个方面。
1）按相关规范使用。在推广微应用平台至平台应用者之前，需要制定一套相应的办法、规范和标准（以下简称规范）以约束微应用产品研发全过程。这个过程中需要开展以下工作：配套规范解读；配套规范监督，为减轻监督成本、提升监督效率，此部分工作最好能通过信息化手段实现，做到将规范融合进平台则是最理想的状态；规范持续完善，规范制定后不应该是一成不变的，而是应根据事情情况随需而动、持续完善，因此需要对应的机制与组织跟进落实此类事项。
2）多重角色式应用。不同的平台应用者在应用微应用平台的过程中要求也不同，对于内部的平台应用者应该同时承担多重角色，既要尽到一个平台应用者的义务，更要做到一个微应用平台的优质用户。包括不限于：应用平台的过程中对于发现的平台的问题需要起到承担反馈问题、提出建议、协助跟进、完成改进等作用。
3）蔓延式扩大范围。主要是指微应用平台首版本发布后，不应急于将平台推广至过多的平台应用者，而应采用逐步蔓延、分批推进的方式，在平台足够完善后，最终达到全面应用的目的。蔓延顺序可参考按研发团队内部应用、责任部门内部应用、企业内部应用、外部研发个体应用、外部研发团队应用、外部研发产品研发商应用顺序依次推广。
4 结语
结合相关理论的研究以及实践过程中的经历，总结出以下相关经验。
1）良好生态需统一全员认识。构建良好的微服务架构生态需要统一全员认识，推进过程中可能会遇到困难阻扰，需携手共进、攻关克难。
2）保持常态化经营生态圈。微服务架构是体系工程，并非一蹴而就，需要以常态化的方式经营整个生态圈。
3）“微应用+ 云平台”模式。数字时代的到来，“微应用+ 云平台”模式将成为企业信息化建设的核心工作。云平台主要是指微应用平台，微应用是指具体的微应用产品。应该将可抽象、复用的组件、控件、服务、接口标准化通过平台层提供给各平台应用者，再由平台应用者基于平台完成具体微应用产品研发。平台层专注于基础技术服务及基础业务组件的抽象；应用层专注于具体的业务规则、业务逻辑、交互方式及用户体验。
4）重视配套体系制度落实。能够科学合理的基于微应用平台进行微应用产品的研发同样也是至关重要的要素。需要一套相应的配套体系制度（包括办法、规范和标准）以约束微应用产品研发全过程。
5）架构无最优只有最适合。随着云计算技术的逐步成熟、稳定，为进一步简化系统复杂性和提升产品研发迭代速度，已有部分企业开始越过微服务架构在研究应用无服务架构。IT 技术架构演进速度很快，并非是选最新的技术架构即是最好的，并非所有应用场景都适合采用微服务架构理念。具体应该选用哪种技术架构，需要视市场环境、企业环境、应用环境、应用场景等多重因素确定。
本文摘自《电力信息与通信技术》
