"IT有得聊”是机械工业出版社旗下IT专业资讯和服务平台，致力于帮助读者在广义的IT领域里，掌握更专业、实用的知识与技能，快速提升职场竞争力。
导语：一个企业的某个或者某几个产品或平台实现微服务化，并不能说明这个企业的整个信息化实现了微服务化。企业数字化转型是大势所趋，建设企业微服务体系又是转型的必由之路，建设企业微服务体系同企业数字化转型一样，都是一个持续改进优化的过程，不可能一蹴而就，也不可畏首畏尾、裹足不前。不同企业需结合自身情况尽快找到一个切入点推进企业微服务体系建设，以实现企业数字化的未来。
Q:
企业为什么要微服务化？
A:
面对互联网的高速发展和强大活力，虚拟化技术、云平台和云原生架构的发展和推进，容器化技术的出现，敏捷方法、持续交付、精益工程等软件工程方法论的快速发展，以及DevOps文化的深入人心等形势，使得传统企业也要变革，也要向市场开放，直接面向用户，增强自身的竞争力。
1
企业为什么需要微服务架构升级
企业的传统IT应用主要以服务企业内部用户为主，其特点是需求明确、功能全面、业务覆盖广，采用中心控制和大集成模式，非常适合企业的稳定和持续发展阶段，缺点是刚性强，难以适应快速变化，运维成本高，无法支持快速变革的业务需求。
新兴的互联网应用的特点则是主要服务外部客户或合作伙伴，需求变动快，功能简单，独立且分散，具有系统从不完善到完善的迭代式演化，业务与IT紧密结合，规模变化大，需要快速创新和大范围的尝试，易失败，也容易被淘汰，对系统软件快速发布要求高。以上这些正好可以由微服务架构应用来满足。
相比互联网企业，传统企业应用想要做到持续集成和快速交付，在企业的架构方面需要向互联网型应用学习，业务应用架构需逐步向微服务架构应用转型升级，提升整体IT建设的效率与可靠性，才能更有效地加速业务创新。
2
企业是否适合微服务化
在采用微服务体系前，企业应当回答以下问题，来评估是否做好准备。
■ 数据量和业务复杂度有没有达到一定量级？若是一个库或一个集群即可搞定，那么建议不要去考虑微服务的问题，大型企业有很多数据库集群去支撑业务，此时才应该考虑实践微服务。
■ 大规模流量并发是否达到一定量级？很多企业将原来系统的业务开了互联网接口就送出去，会遇到很多高流量高并发的问题，这时就需要考虑转向微服务，因为传统架构很难应对突发性流量问题。
■ 是否要求足够的容错容灾？是否需要自动恢复？不是所有的系统都要求100%可靠，对于很多企业而言，一些系统停机一天或几个小时并不重要，其实并非任何系统都要求高可用。容错容灾、自动升级和降级、自动恢复、运维强度等都是需要考虑的问题。
■ 是否需要大量的重复功能建设？是否维护差错成本非常大？系统规模越大，功能的重复就越高，例如现在企业里有很多系统都要进行认证授权，其实可以考虑单独建立一个独立认证授权微服务来实现所有系统的认证，否则每个系统都要建设一次，造成大量重复建设。
■ 是否敏捷？是否严格运用敏捷开发流程和实践，以帮助企业按照不确定/变化的期限完成项目交付？团队是否对这些实践足够了解，以便从面向整个应用的冲刺周期转向专注于多项服务的冲刺周期？
■ 是否自动化？是否使用构建自动化、测试自动化（包括单位、集成和系统）和部署自动化来减少人为错误？是否在每次登入时或至少每天构建和验证代码？是否定期、可靠、可预测地部署现有应用？
■ 是否严格遵守交付原则，而且还愿意尝试和改进？是否树立了专注于服务质量的工程文化？整体文化是否愿意评估风险、进行尝试以及从失败中吸取经验教训？是否愿意改变既定流程和先入之见，以达到团队目标？
■ 是否协调一致？开发、质量、安全、基础设施和运营团队是否合作良好？他们是否采用DevOps 实践以优化业务解决方案的交付？
■ 是否拥有“服务产品思维”？在微服务的生命周期内，必须有人负责其运营。微服务不是开发结束就大功告成，还必须得到有效运行和不断改进。是否树立了产品思维，即生命周期取决于可交付物？这里应注意区分项目思维，即生命周期取决于创造可交付物的工作。
■ 团队规模是否达到一定量级？若团队只有十几个人，很多传统Web三层结构就可以满足需求，无须考虑微服务。当团队规模达到上百人，且拆分成十几乃至二十几个团队，沟通比较困难时，则比较适合考虑微服务。
如果以上任一问题的回答是“否”，那么该组织就不适合立即采用微服务架构，而是应当首先建立相关的适应能力，否则微服务架构就无法发挥其优势。其实微服务架构非常复杂，并不是所有的组织或产品都可以完全掌控和适应的。
3
企业微服务化方法论
企业微服务化实施方法论简介
企业微服务化方法论（Enterprise MicroServices Building Mothed，EMBM）就是针对企业或组织整体的微服务化，基于体系化思维，全方位进行规划、分析、设计、实施和治理的一整套措施和手段，其覆盖微服务体系的业务体系、技术体系和管理体系等各个方面。
EMBM是一个架构框架，也是一个工具包，说明了企业或组织微服务体系设计的方法，依据一套统一架构体系，也解释了统一架构体系如何组成一个整体。EMBM是一种协助企业或组织开发、验收、运行、使用、维护和治理微服务体系的工具，包括一些建议的标准和相容的产品清单，可用于企业或组织实施微服务体系。
企业微服务化方法论的特性
企业微服务体系架构开发方法建立在一个循环迭代的模型基础之上，并且通过定义一系列按指定顺序排列的阶段和步骤来对这一迭代过程进行更加详尽和标准的描述。这一迭代过程中所包含的各个阶段以及每个阶段所包含的各个实施步骤并不是绝对不变的。鉴于微服务本身的开放性和灵活性，针对微服务架构开发方法中各步骤的执行也具备很高的灵活性。EMBM的特性如下。
■ 专注性—从专注微服务体系的视角来展开。由于EMBM主要是基于微服务体系建立的方法论，并不排斥企业或组织中对其他企业架构框架理论（如经典的TOGAF）的引入和使用，因而在多个企业架构框架并存的情况下，企业微服务化方法论各阶段的输入与输出可以不拘泥于EMBM的定义，而可采用适合组织自身情况的其他框架中定义的相关内容。
■ 可调整性和可裁剪性—各个过程顺序可按照实际情况进行调整。企业微服务化方法论中各阶段之间的先后顺序也并不是绝对的，企业或组织可以按照自己的实际情况进行适当的修改。
■ 可适应性—企业或组织的规模和特性千差万别，对企业微服务架构开发方法的适应程度也各不相同。对于中小型企业来讲，如果严格按照上述架构开发方法的阶段定义来执行，其烦琐程度可能会使人们知难而退，因而针对EMBM进行适当的裁剪并使其符合组织自身情况对于各个组织来讲是非常必要的。
■ 迭代性—微服务体系的开发是一个循环迭代的过程，但是并不意味着每次循环都要走完阶段图中所有的步骤；如果有必要，在任何一个步骤的执行过程中都可以根据遇到的情况开展一个新的循环过程。
企业微服务化的8个阶段
企业微服务体系可分为8个阶段，所有阶段都围绕着需求管理这个核心来进行。第1阶段是微服务体系愿景、第2阶段是企业业务架构体系、第3阶段是企业IT架构体系、第4阶段是企业IT架构服务化、第5阶段是企业服务架构微服务化、第6阶段是企业微服务解决方案、第7阶段是实施管理、第8阶段是改进管理。其中第2～5阶段是微服务体系分析内容，第6阶段是微服务体系方案内容，第7、8阶段是微服务体系实施内容，同时第2和8阶段相互衔接，形成微服务体系的迭代内容。
EMBM的各个阶段及其归属如下图所示
EMBM的8个阶段简介：
■ 第 1 阶段微服务体系愿景—包含微服务体系愿景所需的各项活动，如了解业务环境和业务架构，获得管理层承诺，对技术架构范围达成共识，制定微服务体系原则，建立微服务体系治理结构，对本阶段进行裁剪和定制，设定范围、约束和期望，创建微服务体系愿景，验证业务情境。
■ 第 2 阶段企业业务架构体系—包含企业或组织业务架构体系所需的各项活动，如需求的识别、分析和交付，差距分析，确定企业的基线业务架构和业务模型，确定企业的业务架构。
■ 第 3 阶段企业IT架构体系—包含企业或组织业务架构体系所需的各项活动，确定企业的应用架构、数据架构和技术架构，并针对应用场景的架构和模型，最终确定企业的IT架构。
■ 第 4 阶段企业IT架构服务化—包含企业或组织IT架构进行服务改造所需的各项活动，覆盖服务需求、服务分析、服务设计、服务实现、服务发布、服务组合、服务部署、服务监控、服务终结等各个阶段，最终确定企业服务架构体系。
■ 第 5 阶段企业服务架构微服务化—包含企业或组织进行微服务改造所需的各项活动，包括构建企业级业务微服务架构、企业级应用微服务架构和企业级技术微服务架构，最终确定企业微服务架构体系。
■ 第 6 阶段企业微服务解决方案—包含企业或组织微服务体系解决方案所需的各项活动，如形成架构解决方案、进行首次实施规划、识别主要实施项目、对项目进行工作包分组、确定实施方法（包括开发、购买或重用、外包、购买商用解决方案、利用开源软件）、评估项目优先级、识别项目间的依赖关系等。
■ 第 7 阶段实施管理—包含企业或组织迁徙和实施管理所需的各项活动，如确定实施项目和工作包，对实施项目进行成本/收益分析、风险评估，制定详细的实施与迁移计划，监督各个微服务体系实施，定义实施项目的体系约束，治理和管理微服务体系合同，监控实施微服务体系工作的合规情况，确保实现业务价值等。
■ 第 8 阶段改进管理—包含企业或组织改进管理所需的各项活动，如提供持续监控以及变更管理流程，确保以一致性并通过结构化方式来管理微服务体系的变更，确保微服务体系灵活性，使微服务体系能够快速演进、及时响应技术或业务环境变化，对技术和能力管理进行监控等。
工欲善其事，必先利其器。理论和实际相结合，才能具体解决企业架构转型中的问题。
