传统企业微服务架构转型从问题分析到规划实施

　　作者：人月神话，新浪博客同名
　　简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
　　今天继续谈下传统企业微服务架构转型方面的内容，从最基本的问题诉求出发，到整体解决方案的思考，再到开发前的准备，开发和实施工作的重点分析等。企业对微服务架构的关键诉求
　　在前面很多文章里面我们都做过分析，企业转型到微服务架构实际上是增加了企业的IT治理和管控难度，如果企业本身的IT治理成熟度不够往往遇到的问题更大。那么传统企业或者有一定信息化基础的企业朝微服务架构转型的动力究竟在哪里？
　　采用微服务架构，仅仅是引入一种新的开发框架，将传统的单体应用转化为组件化和服务化的架构模式，或者说当前IT架构设计和开发流行微服务架构？感觉很多企业一股脑的上微服务架构，确实存在不少的企业为什么要转型，为什么要实施微服务架构没有想清楚，自身的IT成熟度也没有评估，为了流行或趋势而在不恰当的时间点实施微服务架构，本身就是一种激进的表现。
　　那么微服务架构转型，企业的真实诉求究竟有哪些？
　　共性技术能力下沉，从关注技术到关注业务
　　微服务架构思想带来一个关键点，不仅仅是组件化和服务化开发，更加重要的是平台+应用的构建模式，同时这个应用本身就是能够通过松耦合的微服务模块灵活组装和构建的。
　　这个是转型带来的一个巨大好处，就是传统的一个业务系统的开发模式不存在的了，取而代之的是单独的业务组件或业务模块的开发，通过共性平台层服务能力的支撑，我们不再需要开发重复的类似流程引擎，4A，公共技术组件，而只需要将开发重心真正专注到业务功能和逻辑实现上。
　　有时候我们谈微服务架构就会谈到解耦，但是你微服务模块划分的越细，那么这些模块之间的集成往往更加复杂，再加上很多API接口本身就是同步实时调用模式实现，导致的不是模块高度直治，反而是对外部基础平台或业务组件的依赖更大。
　　提升可变更，可运维，可扩展能力
　　即微服务架构化后，微服务模块间的集成复杂度增加了，如果模块划分的不合理，那么耦合性往往更强。那么将单体应用划分为微服务模块，除了复用基础平台能力外，还有啥好处？
　　这个好处最重要的就是我们管理的单位更小，对于后期的IT运维和变更处理更加方便。这种方便性体现在业务模块的性能扩展，也体现在业务模块的功能和业务变更重新部署和发布。你会发现这些事务的影响比原来更加小。
　　比如一个微服务模块变更，如果其接口没有变化而是内部逻辑变化，那么我们只需要对该模块进行变更，并只对该模块进行测试和发布即可，而不会影响到其它的业务功能组件和模块。
　　同时在微服务架构下，我们更加容易实现微服务模块的动态热部署，在和容器技术结合后更加容易实现动态资源弹性扩展。
　　提升甲方对整个IT应用的过程管控能力
　　这个是微服务架构实施后带来的一个重大好处，即原来是一个大的业务系统开发，那么业务系统内部开发商过程如何管控，质量如何，内部组件接口是否设计能力，该暴露的能力是否暴露，这些内容对甲方来说都是黑盒，根本就无法展开有效的过程和质量管控。
　　而在实施微服务架构后最大的好处就是甲方的管控细化到微服务模块，即真正打开原来开发商的内部黑盒，可以细化管理到每个模块的交付，接口，过程质量，这带来的是一个重大的甲方管控能力提升。
　　由于单体应用被拆分，强势的甲方还可以提前制定好微服务架构开发框架和模式，引入DevOps过程和方法论，同时引入多个开发商来共同开发多个微服务模块，真正将开发过程可视化，持续集成过程可视化，由事后的验收和质量控制转变为过程中的随时管控，真正避免后期被单一开发商绑架的问题。
　　自动化和效率提升
　　自动化一定是微服务架构实施的另外一个受益点，这个自动化包括了DevOps过程自动化，也包括了后期运维监控，变更发布过程的自动化。如果一个微服务架构实施没有能够实现自动化，反而投入了更多的人力资源来实现过程管控，后期的运维监控，那么微服务架构实施的初衷都没有达到，不仅仅是增加了开发运维工作量，同时也增加了整体运维和管控的难度。
　　当然这个自动化的实现，一个是涉及到开发商的能力水平，同时本身也涉及到甲方本身的信息化经验和成熟度，两者缺一不可。
　　互联网各种最佳实践相对多，一定要意识到有些东西在短时间并不适合马上应用到传统企业。这不仅仅是IT能力方面的问题，也涉及到业务模式和管控本身的差异。
　　微服务架构下是我们前面谈过的SOA关键思想的落地，即真正实现业务能力组件化和组件能力服务化，同时实现前端应用的可组装化，只有这样才可能真正搭建灵活的SOA架构，实现当前IT架构对业务变化，新业务模式开展下的快速响应和支撑能力。
　　快速响应并灵活的支撑业务，是微服务架构带来的另外一个关键业务价值实现。微服务架构转型-方案制作
　　如果要做一个给传统企业讲解的企业微服务架构转型的方案，那么这个方案应该做？
　　对于传统企业转型微服务架构，包括涉及到工作内容和范围，技术的关键点，实施方法等在前面博客多篇文章中都进行了详细的阐述，那么要做一个面向企业宣讲的技术方案材料，初步考虑整体搭建思路应该为：
　　01-传统企业IT架构的问题
　　系统是建设的最小单位，那么这里的业务系统实际就是我们说的单体应用，讲问题实际上更多是讲传统单体应用存在的问题有哪些？
　　如果从整体生命周期来看，实际上是可以从规划选型期，开发建设期，运维期几个方面来谈。本身里面又包括了软件工程，项目管理，过程支撑三个维度的内容。
　　规划选型期更多选择是厂商比较产品化的产品，你很难去定一套技术架构，开发标准和规范体系，这也是后续导致整体IT架构里面多语言，多数据库，多开发框架，多接口类型的一个主要原因。
　　对于开发建设期，实际上最主要的问题还是整个业务系统里面各个模块间紧耦合，无法拆分，其次就是大量共性的内容重复建设的问题。这里可以画图描述，如何把各个业务系统共性内容统一掉，并下沉到平台统一建设，构建平台+应用，应用层通过微服务模块构建思路来完全松耦合。
　　在开发建设期，实际上还需要谈一个重要问题，就是传统建设模式下响应变化的能力弱，都是业务需求和功能，前端和后台逻辑完全绑定死的。而实际上引入SOA思路和微服务架构化后，应用构建逻辑发生了变化，即核心的SOA思路：
　　即先搭建中台（技术中台+业务中台），然后暴露中台关键能力和服务，再由这些服务来组装上层的关键前端业务和流程。
　　对于标准规范体系，实际上仍然是包括三个方面的内容，项目管理类，软件工程类，过程支撑类，再加上后续运维期的的话还包括IT治理和服务治理类。本身这些规范如何和敏捷方法论，DevOps和持续集成等融合。规范作用一个是使过程标准化，模板化，其次是加强甲方对整个项目的管控力度。
　　02-微服务架构概述
　　方案里面还是需要对微服务架构做一个简单的介绍，即解释清楚什么是单体应用，什么是微服务架构，微服务架构的核心是什么？其次解释清楚微服务架构和SOA的关系。
　　对于微服务架构进一步解释清楚判断的标准是什么？
　　同时要说明清楚，要实现一个完整的微服务架构，需要满足哪些判断准则，同时在微服务架构里面有哪些关键的核心组件，这些组件是起什么作用？具体选用的标准是什么？
　　在这里可以讲解下SpringCloud框架以及框架中的各个开源组件，并把每个组件本身的作用讲清楚。但是最后一定要强调到，不是采用SpringCLoud框架就是微服务架构，SpringCLoud框架只是微服务架构里面的开发框架部分内容。
　　微服务架构业界通用的一个定义是如何的？
　　微服务架构的判断标准和准则，可以表格化来说明。微服务架构实现中最基础要具备的能力(开发框架，注册中心，负载均衡，服务网关，流控+熔断，安全）
　　微服务架构化和传统企业业务系统间SOA集成的差别在哪里？
　　实际上我们看到最主要的就是SOA集成思路深入到了业务系统的内部，业务系统本身的各个组件变化为微服务模块，共性组件变化为采用平台层能力，微服务模块间通过Rest接口服务集成。
　　如果单业务系统还是一个厂商来做，实际上单业务系统本身就是一个SpingCLoud框架体系，通过服务网关发布接口服务能力，同时将接口服务进一步注册到跨系统的轻量SOA服务总线上面来。即实际上的接口服务集成可以理解为两层的集成，内部仍然可以走注册中心点对点集成，有需要发布到外的通过微服务网关通过二次注册将能力发布出来。
　　一个企业应该如何实施微服务架构？实际上在前面一篇文章里面已经谈到，应该包括了咨询和规划，开发和构建，管控和治理三个方面的内容。后续的介绍可以围绕这三个方面的内容展开。
　　注意：这里应该有一个完整的阶段模式的流程图来说明，一个完整的微服务架构规划建设和实施过程是如何的，即包括了前期的规划阶段，开发建设阶段，后续的运维治理阶段。要体现每个阶段究竟是完成什么关键工作，每个阶段是如何衔接的。
　　这张图实际上相当关键，即后续你要展开描述的内容都应该在这张图上有体现。
　　03-微服务架构-咨询和规划
　　咨询规划做什么事情？首先应该是调研清楚当前企业的IT架构是如何的？当前的架构下存在什么问题？然后是给出企业本身的微服务架构转型思路，具体的微服务架构演进路线。
　　在演进路线规划完成后，在第一阶段，比如对一个老的应用系统进行迁移或者一个全新的业务系统进行微服务架构开发，那么我们就需要基于这个实际的需求来分析如何进行微服务架构的实施？里面的关键点仍然是如何划分不同的微服务模块？如何定义清楚微服务模块间的接口关系？如何拆分好不同的数据库？这些顶层设计工作都必须在前期做完。
　　对于咨询规划阶段，重点应该包括如下几个方面的关键内容微服务模块如何拆分，包括了业务模块的拆分，包括业务模块对应数据库拆分在拆分过程中，微服务接口如何识别和定义，微服务模块间的接口集成关系是如何的？平台层能力如何识别，共性能力如何下沉，包括了技术中台+业务中台。基于微服务架构模式下整体应用架构，技术架构，集成架构，数据架构的规划是如何的？基于微服务架构下的开发标准，规范体系基于微服务架构下的项目管理，过程管理，运维治理规范体系。
　　04-微服务架构-开发和构建
　　开发和构建实际上最好的方法是，我们只进行类似4A，流程引擎，MDM主数据等平台层微服务模块的开发，而对于业务类微服务模块只是划分清楚模块，定义好接口，而实际的开发则转给企业内部开发人员或其他开发商进行。而我们需要做的就是整体的项目群管理，后期的多个微服务模块间的集成。
　　即我们拆分好微服务模块和数据库，定义了一套标准规范体系和技术开发框架，然后找了不同的开发商来进行多个微服务模块的开发，我们最终要保证开发完成的内容能够完整的集成起来，并满足端到端业务流程的需要。同时我们会实施一套过程支撑工具来实现对DevOps过程的可视化支撑，通过过程支撑工具可以实现对整个应用开发的完全自动化，可视化管理能力。
　　这里重点实际上是基于规划阶段讲解的总体思路和内容，来演示清楚如果一个厂商单独构建一个微服务模块整个开发建设的过程是如何的？
　　我们大的原则就是厂商内部可以走独立的SpingCLoud框架体系，但是厂商和厂商间接口服务集成，走外部的SOA服务总线来实现治理和管控。在这里的一个前提是厂商进行微服务模块的开发时候，前面的整体架构设计工作应该已经完成，即模块和数据库已经划分好，接口也已经定义好。
　　这个过程就是微服务架构模式下的实施过程，即厂商如何进行开发，接入如何发布和注册，如何消费接口，如何进行开发，如何提交部署和发布等一系列问题。这个和我们原来讲的私有云PaaS平台思路是相当类似的。
　　首先从大思路和流程上讲清楚如何做，其次还得讲清楚两个层面的内容，比如选用了SpringCLoud框架来实现微服务模块，那么基于SpringCLoud框架如何来做开发，开发完成的接口服务如何提交注册，如何消费外部接口，如何和其它微服务模块集成和联调。如果启用了容器化部署和DevOps，如何和这些支撑平台更好的集成等，这些都需要进一步描述清楚。
　　以上都描述清楚后，接着讲微服务架构+容器化+DevOps结合的最佳实践，同时来介绍整个融合的过程和DevOps支撑平台和工具集。即通过这个支撑平台和工具集，如何更好的实现了敏捷和自动化，如何更好的支撑整个微服务模块开发和集成的过程？
　　05-微服务架构-管控和治理
　　整体微服务架构最终上线后，马上面临的问题就是运维管控问题。
　　在运维管控上面需要考虑的内容就是微服务架构整体体系如何监控和运维？这个监控运维即包括了资源层面的，也包括了服务和服务链监控等APM层的内容；其次还需要考虑在整个架构体系下，变更如何处理？版本如何发布？
　　这些基础的指导仍然是类似ITIL标准的方法论，但是在微服务架构和支撑平台实施后，类似问题管理，变更管理，运维监控，版本发布等流程都需要配合微服务架构进行相应的调整和定制。比如在实施了DevOps和容器化部署后，对于整个部署过程都是自动化进行的，和原来的手工部署就寻找较大的差异。整个建设期软件开发过程的管理和管控运维期功能和接口服务变更的管理和管控涉及到ITIL相关的内容，特别是问题管理，变更，日常运维，配置管理等平台的运维监控能力，性能分析，服务链监控
　　06-企业实施微服务架构实施
　　在这里需要介绍企业微服务架构实施步骤和演进路线规划。同时详细的介绍全新开发构建和遗留系统逐步迁移两种方法下的实施方法区别等。
　　当然，光说好的地方还是不行，对于企业是否实施微服务架构，微服务架构本身存在哪些问题也需要一并进行介绍。实际上讲风险点，更多的应该是讲企业要实施微服务架构应该进行的前期准备工作，包括了已有的IT积累，人员积累，企业本身的IT项目管理成熟度和规范化等，这些内容都必须要强调到。
　　举个简单的例子，原来是6个业务系统，微服务架构化后变成了60个微服务模块的管理和监控，如果后续的运维监控能力跟不上，对于后续的运维和变更管理反而是灾难。微服务转型-架构规划
　　在架构规划阶段和传统的企业架构规划的差别点，对于企业架构规划我在前面很多文章里面都详细阐述过，主要还是基于标准的Togaf方法论，以业务驱动IT，从流程分析入手，依次对业务架构，数据架构，应用架构（包括集成架构），技术架构的规划。
　　微服务架构，简单来说就是原来的单体应用的微服务模块化，同时对于原来的集成接口服务化，这和我原来强调的业务能力组件化和组件能力服务化是一个思路。也就是说我们整个管理的最小粒度发生了变化，从原来的单体应用变化到了微服务模块。
　　那么为了达到这个要求，在规划阶段究竟要做哪些事情？或者说如果仍然按照企业架构规划的思路，在结合微服务架构思想的时候，应该做哪些改进才能给更好的匹配。
　　01-业务架构和数据架构
　　对于端到端流程分析和业务架构阶段，基本上不受影响，还是按照传统的业务架构分析方法进行即可，只是对于业务架构本身的多层视图要更加清晰，从业务价值链到业务域，从业务域到业务组件模块。业务组件还可以考虑分层，特别要注意的就是业务组件本身是比原来的业务系统粒度更小的单位。
　　基于业务流程的分阶段，基于原业务部门的分科室，仍然是我们找寻独立自治的业务组件模块的核心方法。
　　当我们在观察企业内部的业务部门或科室的设置时候，也会发现两种情况:一种是以数据为核心的，比如供应商管理部。一类明细是有业务活动为核心的，比如商务洽谈科。
　　而实际我们在后面拆分和构建微服务模块的时候仍然是这两类，数据类+业务活动类。只是再增加了技术类而已。
　　数据架构分析，核心思路仍然一样，但是会更加强调数据的CRUD分析，同时强调数据域的划分。对于数据对象不是很粗的确定要业务域，而是要确定到具体的业务组件模块。即你要确定你识别和定义的数据对象，其核心的Owner是哪个业务模块。即我们传统的数据库DB在微服务架构下是要拆分到组件和模块级的，即模块划分好后，模块对应的数据库表也要归属清楚。
　　在数据架构规划和分析的时候，一定要加强对基础主数据，核心共享动态数据的分析。可以看到，在后续构建整体基于微服务架构应用的中台时候，核心中台组件来源于基础主数据和核心动态数据。业务组件模块和底层数据拆分域是对应关系，1个数据拆分域只能有一个Owner的业务组件。但是一个业务组件却可能没有对应的底层数据对象，即该业务组件只是调用其它业务组件的数据能力。
　　应用架构规划这里存在大变化，即进一步强化平台+应用的构建思想。同时对于应用层又体现了一个关键的概念即业务中台的构建。
　　原来规划应用架构，每一个应用都涉及到系统管理，流程引擎，消息缓存等技术组件，上层才是具体的业务功能模块，而新模式下所有的技术组件全部下沉到技术平台层，这和多年前我博客里面强调的私有云PaaS平台构建思路完全一致。只有技术组件下沉到平台，上层的业务模块才能被彻底的微服务模块化和组件化。
　　02-应用架构的规划和建设
　　首先要考虑刚才谈到的技术平台的规划和建设，哪些放到技术平台去做，形成平台+应用的构建模式。其次考虑中台规划和建设，注意在传统企业架构规划-应用架构规划设计中是没有这个概念的。而在微服务架构模型下，结合SOA架构思想，增加了中台规划和建设的思路。
　　如何构建中台，即中台应该包括了哪些中心，如何更加中台的数据和业务能力来组装和编排上层的业务，这些都在应用架构规划的时候要考虑的事情。对于中台如何构建，我们前面博客有专门的一篇文章来说，在这里就不展开。但是在应用架构规划中重点就是要规划清楚中台的微服务模块，前台的微服务模块。中台的模块更多的是数据提供中心，规则中心。前台的模块更多的是业务协同中心，业务流程处理单元。
　　应用架构重点就是要确定微服务模块，微服务模块本身和前面业务架构规划的业务组件是对应的。在微服务模块的规划和定义中，要确定哪些业务功能在该模块，哪些能力提供在该模块，哪些数据Owner到该模块。同时要分清楚了微服务模块本身的三种不同类型。1无前端界面，仅仅提供接口服务能力的模块。无后端数据库，仅仅是组合已有微服务模块的API能力接口。前端+后端，即既有Owner的数据库，同时也有前端功能界面。
　　在微服务模块划分清楚后，接着要做的仍然是微服务模块间的集成关系规划，即每个微服务模块究竟应该暴露哪些API能力接口，同时又需要调用哪些其它模块提供的API接口。
　　实际上我们在看很多采用SpringCLoud开发框架进行微服务模块开发的项目中，各个微服务模块之间仍然紧耦合，核心原因除了模块划分不合理外，其次就是各个微服务模块间的API接口调用相当虽然，不受任何控制。可想而知，在这种模式下，微服务模块间是很难做到真正的独立自治的。
　　我们这里指的微服务模块仍然是大模块的概念，即传统的一个单体应用拆分为6-8个微服务模块的粒度比较适合。
　　比如一个供应链管理系统，那么招投标，采购，供应商管理这些就是独立的微服务模块。在这种方式拆分后你会发现一个采购模块可能仍然还复杂，里面还需要进一步细分为不同的功能组件，那么这里的思路就是在一个微服务模块本身内部还可以拆分微服务组件，一个微服务模块就是一个独立的SpingCloud体系，有独立的注册管理中心，服务网关能力。
　　对于内部的微服务组件间的交互可以不用精细化管理，但是大的微服务模块间的接口交互就必须通过服务网关暴露的接口服务进行协同，并严格受控。
　　03-技术架构规划
　　对于技术架构规划，这里不展开谈。有两个点要关注。
　　第一就是基于微服务架构的技术架构，开发框架，运行期框架，包括微服务架构规范标准体系这套东西要完整，以指导开发商进行微服务模块的开发和集成工作。
　　第二就是对于PaaS层中间件资源池，需要结合最新的容器技术来规划，要考虑容器技术如何和微服务模块，DevOps过程集成在一起的。微服务转型-前期准备和开发思考
　　再次强调，对于传统企业的微服务架构转型，和我在12年开始博客上写作的企业私有云架构平台相当类似，其核心仍然是共性技术能力下沉形成平台+应用(微服务模块）的构建模式，其次就是传统单体系统彻底的进行组件化和服务化的改造。
　　其中变化的点只是在于从传统的PaaS变为了轻量的基于Docker容器+K8s的轻量PaaS平台，对于微服务模块的开发建议采用标准的类似SpringCloud开发框架，对于接口服务集成转变为Rest接口服务集成，对于在私有云架构里面我谈到的持续集成进一步完善为了完整的DevOps方法论。
　　因此对于企业实施微服务架构转型，仍然可以先参考我原来的文章，特别是里面的组件化架构和组件化开发部分，一定要清楚部署你采用了SpringCloud和Rest接口服务集成，就是微服务架构，技术人员崇尚技术，但是最容易犯的毛病就是认为技术就是架构方法论，认为采用了WS服务就是SOA，认为采用了SpringCloud就是微服务架构等。
　　注：对于企业私有云PaaS平台规划，架构，可以参考我最近出版的《SOA与大数据实战：企业私有云平台规划和建设》一书，里面有详细的内容介绍。
　　对于传统企业的微服务架构转型，包括实施前的准备，我在博客上已经写过一些专门的文章，这篇文章主要还是基于前面文章写的核心思路进行一些关键内容的细化思考。
　　对于共性技术平台的能力下沉和微服务模块化
　　单体应用原来一般都会带系统管理和流程引擎，基础共性技术模块等能力。但是在单体应用拆分为微服务模块后，每个微服务模块一定不能再保留这些内容，而是应该下沉到共性技术平台，技术平台再以服务化的提供这些能力。即我们常说的4A模块，流程引擎模块，技术服务模块（可能包含多个，类似消息，缓存，文件，通知等各种技术服务能力）。
　　每个技术模块本身就是一个微服务模块，可以独立开发，部署和管理运维。每一个技术模块都必须实现多租户能力，即应用层的各个应用产生的微服务模块都是技术模块的租户。技术模块提供技术服务能力，这些技术服务能力需要考虑足够的可复用性，服务高可用性和可管理性。
　　共性技术平台必须先行，这些共性技术能力剥离后上层的业务模块才能够真正变得足够轻量，只需要去关注自己业务模块里面的业务功能和逻辑的实现即可。企业在实施微服务架构的时候一定要注意到这个平台的重要性，只有把这个建好，才能够为你上层的业务模块开发提供足够的支持。
　　原有的单体应用拆分为微服务模块
　　注意，这个是业务问题和总体架构设计的问题，而不是技术问题。对于原有的单体应用拆分不要超过8个微服务模块，一般为4到6个即可。微服务模块拆分的越细，各个微服务模块之间的集成和协同就越复杂。要知道每个微服务模块就是一个小应用，需要能够独立完成需求，设计，开发，测试，部署上线和运维工作。
　　一般微服务模块的拆分思路可以参考原来应用在进行业务架构设计，总体架构设计的时候模块划分的方法进行，但是这个不绝对。判断拆分的关键标准还是拆分后是否足够的松耦合，是否能够满足完全独立管理的需要。举例来说如果一个模块拆分出来，需要和其它所有微服务模块都交互，大量的接口调用，那么这个微服务模块拆分出来没有任何意义。
　　再简单点来说，以流程驱动的应用系统，可以以端到端流程大的阶段来进行模块拆分，以数据为主的应用应该在进行数据CRUD分析后以数据域划分思路进行微服务模块的拆分。
　　注意，在进行独立的多个微服务模块开发前要进行的一个关键工作就是进行微服务模块的拆分，第一个是要把各个模块拆分好，第二是要事先定义好各个微服务模块间相互调用的接口。原来这个工作是在应用内部完成，但是现在这个工作应该被单独拿出来进行规划，这个架构设计的动作不能少，否则就容易在后面出现微服务模块开发和接口管理失控的混乱。
　　怎样保证每个微服务模块的足够独立自治，如果一个人开发两个微模块模块，要实现两个微服务模块的完全独立是很难的事情，你总会发现在私下发生的一些不规范和不严谨的调用。因此最佳的做法仍然应该是开发每个微服务模块的开发小组完全独立运作，但是允许这个开发小组只有一个人的场景。只有这样，微服务模块间的协同才可能由隐性转变为显性。
　　关于开发环境的搭建和准备问题
　　对于传统开发，如果我们谈到开发环境，那么一般只会说到开发数据库，而对于应用中间件一般都在我们本地启动和运行，方便进行开发自测和调试运行即可。而到了微服务架构下你会发现一个大的变化点，就是你自己的微服务模块往往在你本机环境是无法正常运行和跑起来的，你的模块要运行起来需要调用其它微服务模块的Rest接口服务能力，那么就需要这些微服务模块处于运行状态才可以。
　　同时微服务模块大原则要求就是数据库一定是拆分的，你只能访问和控制你自己的数据库，而其它微服务模块的数据库你都无法访问，因此更加无法在开发中直接去访问数据库完成相关的业务了。
　　因此在微服务架构开发下，必须要有开发环境，类似前面说的4A，流程引擎，技术服务能力都必须要提前部署到开发环境去。同时你自己开发的微服务模块有两个思路，首先当你作为接口服务能力提供方的时候，你必须要及时的将你的模块部署到开发环境上面以方面其它模块使用，其次当你作为消费方和自己代码功能调试的时候，你可以在你本机环境运行你的微服务模块，但是对于访问的外部接口服务地址都来源于开发环境各个模块提供给你的能力接口。
　　一定要注意，在进行了微服务模块拆分后，集成和协同的难度一定是增加了，同时对于整个微服务架构下的管控和治理难度也进一步提升。但是好处就是原来单体应用内部模块间不规范和黑盒的东西全部暴露了出来，对于管控的精细度也进一步加强了。
　　再次强调下不要将微服务架构简单理解为SpringCloud+Rest接口，更加重要的是组件化和服务化，平台+应用的IT构建思路。
　　为何说微服务模块不适合划分的太细，上面已经讲过的划分的越细集成的难度就越大。在上篇文章里面有个点没有谈到就是微服务模块本身是需要带自己Owner的数据库的，而各个微服务模块对应的数据库是完全拆分的，这才是典型意义上的完全微服务架构化。
　　微服务拆分关键-数据库拆分
　　前面讲了可以按业务阶段，按数据域来划分微服务模块，在微服务模块划分的时候不仅仅是前端业务功能的划分，更加重要的是后端的数据库表的Owner的划分。即要搞清楚每个微服务模块究竟管理哪些数据库表，每个微服务模块对应的数据库，要么有核心的业务对象和数据对象，要么就是有核心的业务规则逻辑。
　　数据库划分清楚后，各个微服务模块完全独立，数据库之间是不能有相互交叉访问的，那么微服务模块间只能通过Rest接口进行交互。Spring Boot框架中很方便将Java API方法暴露和映射为Rest接口，这就很容易导致接口滥用，这也是前面一篇文章我重点强调了微服务模块划分好后，在架构设计的时候就要完成接口设计和定义，然后再开始各个微服务模块的并行开发，然后再进行集成。
　　由于数据库的拆分和采用无状态的Rest接口服务，必然导致前端开发的复杂化，同时导致分布式事务问题，这个在博客前面很多文章都已经描述过，在这里不再展开。
　　一个前端的微服务模块完全可能是不挂数据库，仅仅是使用底层中台各个模块暴露的接口服务能力，也可能挂一个数据库，但是该数据库仅仅是存储临时数据和单据。同时一个微服务模块也完全可能仅仅是提供中台接口服务能力，而没有前端界面，对于前端完全支撑各种多样性和灵活性，但是最终的数据需要落地到该中台数据模块。
　　同时还有一类微服务模块，本身类似在SOA架构设计中的组合服务能力提供，即更多的是提供整合后的组合服务能力，同时做好事务处理和一致性管理，这类微服务模块本身也可能不挂数据库。
　　简单来说，就是微服务模块化拆分的时候除了纵向的微服务模块是松耦合关系外，对于涉及到 数据库+中台模块+前端模块 这三者之间也是松耦合关系，可以根据业务的需要灵活的进行组合。
　　开发前期准备-接口部分
　　在要正式开始一个微服务模块的开发的时候，开发前期的准备一个重要工作就是接口部分的准备。即你首先要搞清楚你这个微服务模块要能够成功的运行起来，你需要调用底层技术中台哪些接口服务能力，同时你需要调用其它业务微服务模块哪些业务Rest接口服务能力，同时你又需要暴露哪些接口服务能力给外部其它微服务模块用。用硬件里面话来说，就是你要把自己这个微服务模块的南向接口和北向接口全部搞清楚。
　　而这些也正是为上篇文章里面谈到的，在整体应用的架构设计的时候，就应该把微服务模块划分好，应该把每个微服务模块的南向接口和北向接口能力规划和定义好。这才是一种自顶向下的设计思路，而不是后面想到哪里做到哪里，缺接口又随便添加，导致后面微服务模块间的接口交互完全失控。
　　对于技术中台而言，往往一开始就可以将规划和定义好的服务接口发布出来并部署到开发环境，但是对于业务微服务模块间的接口就需要在各个开发小组开发过程中协作完成，那么我们就要注意，当你开始开发你自己的微服务模块的时候，更加重要的是先开发你需要对外提供和暴露的接口服务，因为只有这样才不会影响到其它开发团队的开发工作。否则，你就自己需要写服务模拟端代码，以确保你的模块能够正常跑起来。因此，我们建议的方法仍然是各个微服务模块开发的时候接口先行，其次才是开发内部功能和业务逻辑。
　　其次，不管是对于接口的消费，还是接口服务的提供，最好有独立的Proxy代理类来进行管理，即所有的对外出口和对外入口，都有统一的Java类来进行代理。因为我们实际在使用Spring Boot框架的时候，容易出现在很多个Controller类里面都出现接口开发和映射注解，如果我们要查找究竟开发和消费了哪些接口后面自己都不好查询，因此建议还是通过统一的Proxy代理类进行接管更好。
　　单个微服务模块本身的前后端分离
　　再考虑下如果对于单个微服务模块本身进行了前后端分离，即对于业务逻辑层+接口服务暴露单独进行打包，对于前端应用开发单独进行打包。那么在这种情况下前端应用是否全部通过Rest接口服务进行底层能力访问呢？
　　实际在在整个微服务架构开发里面，对于微服务模块应用自己Ower的数据库操作，我们并不建议去走Rest接口服务去交互。举例来说1个微服务应用的前端和后端可能有100个接口交互点，而这100个接口交互点里面往往只有10个接口涉及到和外部微服务模块交互，因此只需要将这10个接口暴露为Rest接口服务并注册到注册中心目录库即可。
　　最好的方式就是同样一个API方法即可以实现内部调用使用，又很方便的通过注解发布为Rest接口服务能力供外部微服务模块访问。即满足接口交互和协同的需要，又满足内部模块性能和开发效率的需要。
　　其次，单个模块在构建的时候前端和后端模块分离是必须，即对于前端模块和后端模块完全可以进行独立的打包，同时前端和后端可以安排给不同的团队或不同的人独立开发。即我们看到对于微服务模块首先安排到不同搞得开发小组和团队，其次对于微服务模块进一步拆分为前后端，可以安排到不同的人。前端开发负责前端界面展现，服务能力的组装，交互设计和协同；后端模块人员负责API接口能力的开发和暴露。
　　注意，在这种前后端分离的情况下，可以更加方便我们后面直接对微服务模块API接口进行自动化的单元测试操作，这个可以和DevOps和持续集成做到无缝对接。微服务转型-和敏捷方法论集成
　　对于敏捷方法论我前面也有很多文章都谈到过，敏捷方法论里面核心的内容仍然是短周期迭代，持续集成和可视化，条目化需求管理和跟踪等。
　　对于以上内容即使你不实施微服务架构，仍然都可以采用。在谈敏捷方法论的时候我曾经谈到过，如果是对于一个全新开发的系统，特别是底层模型复杂的时候，往往很难实施敏捷方法论，因为对于这种全新系统在前期保留架构一致性相对重要。
　　但是如果一个全新的系统，能够在前期提前先做好微服务模块的划分，做好总体架构设计，数据模型设计和各个模块的南北向接口设计和定义，那么实际上前期架构一致性的工作就基本完成，那么对于每个已经拆分后的微服务模块，这个模块本身的功能点，对应的数据库，包括消费的接口，提供的接口这些内容都完全清楚了，那么对于模块里面的各个功能点完全可以做到按敏捷方法论进行功能需求的条目化，并进行短周期迭代开发。
　　对于微服务架构和敏捷方法论在前面很多文章都已经详细谈到过，因此在这里只谈微服务架构和敏捷方法论在集成过程中涉及到的一些实施关键点。
　　首先，对于敏捷团队本身跟着微服务架构进行拆分，即对于负责不同的微服务模块的团队单独拆分开，每个团队都会有对应的需求，设计和开发，测试人员。对于微服务模块本身需要独立自治，因此对于开发每个微服务模块的团队本身也是高度独立自治的，能够完成自我运转。
　　在拆分后，每个微服务模块的开发，完全可以按照传统的敏捷方法论进行管理和监控，包括相应的需求条目化拆分，基于UserStory主线的跟踪和管理，燃尽图等实践都没有问题。但是在做这个事情之前，敏捷团队一定要意识到，模块的成功运行需要依赖外部的接口服务能力，这些接口服务能力必须提前得到管理和监控，作为模块开发进度的关键前置依赖，否则将很容易由于外部原因影响到自身模块的开发进度。
　　其次，对于持续集成这块，我们首先可以做到的就是在编译期无组件依赖，确保自身的微服务模块可以正常编译打包和部署。然后就是在持续集成后完成后需要进行单元测试，这个单元测试需要优先进行你消费的接口和你提供的接口的单元测试，其次才是内部业务功能的单元测试。对于模块的自动编译打包和部署，在采用容器资源池后，还需要和容器部署进行集成。
　　即在前面讲的编译和构建-》形成部署包-》镜像制作-》容器化部署和托管。
　　在实施DevOps方法论后，上面整个过程需要做到完全的自动化，即每天下班你只需要将本机编译通过的代码检入配置管理库，其它的工作都应该是自动化完成，包括编译打包，部署和单元测试。
　　在微服务架构场景下，将更加关注多个微服务模块间的集成测试，同时这类集成本身还具备有前后关系，哪些模块或接口应该先集成，哪些应该后集成，这些整个产品集成规划和执行本身是在敏捷方法论外的内容，需要单独进行考虑和设计。
　　最后，需要考虑形成两级的敏捷项目管理方式，即首先是单个微服务模块本身的敏捷项目管理，其次是多个微服务模块组成的完整应用的敏捷项目群管理。单个微服务模块的项目管理由各自的敏捷团队自己完成，对于项目群的管理，则需要专门的人来进行管理和监控。实际上项目群管理的关键问题仍然是在前期微服务模块的拆分，接口的定义和依赖，后期的多个微服务模块的集成关系和顺序。只有这些都梳理清楚了，多个微服务模块间才能够很好的完成协同形成一个完整的应用。
　　简单的看板实际上很难完成上述的项目群管理工作，因此对于项目群的管理和监控仍然需要使用能够明显表达出前后依赖关系的可视化进度图表来进行展示，比如甘特图等。对于项目群的管理，个人认为是一个大的IT应用拆分为微服务架构后，实际上确保项目能够正常执行和功能集成的关键。微服务转型-实施前技术储备
　　前面已经谈到过，微服务架构不是简单的微服务开发框架的使用，更不是简单的Restful接口的使用，而是大量的SOA，持续集成，组件化和服务化，云平台和容器，DevOps等思想的融合应用。因此在考虑转型到微服务架构的时候可以首先进行相应的准备，而这些准备基本都是可以独立完成并实施的，具体如下：
　　持续集成实践：在很早就有持续集成的思想和最佳实践，里面涉及到配置管理，自动编译部署，环境迁移，自动化的单元测试，每日构建和冒烟测试等方法和实践的使用。这些即使没有实施微服务架构，对单个业务系统也可以进行持续集成的实践。持续集成和自动化的构建是后续微服务架构和DevOps的一个重要内容。
　　领域建模思想：对于领域驱动架构是面向对象分析和设计中的一个重要内容，通过领域服务层的构建可以很好的解决业务高内聚和粗粒度的服务接口提供的问题，而不是简单的将对数据库表的CRUD操作发布为服务接口，同时领域建模也很好的解决了原有的贫血业务逻辑层的问题，真正在业务建模和架构设计阶段，从对数据对象的关注转移到对业务领域对象的关注。粗粒度的服务接口即使在实施微服务架构后也是必须关注的内容，否则会出现微服务模块间大量的接口交互的场景，这种接口越多越导致了微服务模块之间越紧耦合。
　　SOA思想的深入理解：对于微服务架构实际上是SOA参考架构思想在原有的单体应用内部的实践和落地，因此SOA思想是基础，而SOA思想本质就是业务能力组件化，组件能力服务化，将业务流程或业务的实现转变为多个松耦合的业务组件（微服务模块），同时通过微服务模块暴露的API服务接口实现组件之间业务功能的组合和编排，以完成完整的业务流程。
　　微服务开发框架的学习：比如对当前主流的Spring Cloud微服务框架的学习和理解，其中包括了服务目录和服务注册，微服务网关，服务的发布，服务后续的管控治理，服务运行监控等诸多内容。这些都需要去学习和理解。通过微服务开发框架，真正实现了各个微服务模块的开发完全独立自治，可以独立进行设计，开发和最终的部署。而微服务模块暴露的服务在注册到微服务网关后又实现了多个微服务模块之间的联动。
　　关键技术的学习：这里面主要包括了Web Service，消息中间件，事件引擎，Restful接口和面向资源的概念，CXF开发框架，Spring Boot和Spring Cloud，Maven构建，DevOps，云和容器技术，前端技术等。这些都是在微服务架构实现和微服务模块开发中会用到的内容，需要学习和掌握。
　　基础平台和技术组件和服务的学习：这里面包括了常用的工作流引擎，4A和权限管理，日志管理，缓存，文件服务，ETL数据集成，消息和通知等，这些也都是在实施微服务架构的时候可能会下沉到基础平台层统一规划和实现的内容。
　　软件过程改进方面的内容：企业遵循什么样的软件开发过程和软件生命周期模型？是传统方法还是敏捷方法论？需求，架构，设计，开发，测试，发布完整的流程是如何的？对于配置，变更，评审和Review等过程又是如何的？这些都需要有一定程度的定义和标准。即使实施了微服务架构，也需要遵循传统或敏捷的软件工程方法论。而在微服务架构中，很重要的一个就是微服务模块的划分，微服务API接口的识别和定义，我们可以在传统方法论中进一步补充这方面的内容。微服务转型-实施步骤
　　今天还是想在谈下企业微服务架构转型中详细实施步骤的一些细节问题。在前面的文章中已经谈到过微服务架构转型中的实施策略，今天重点谈下微服务架构转型中的实施步骤。
　　步骤1:4A和流程平台的下沉和能力开放
　　这个是我谈的最多的问题，即在实施微服务架构转型的时候必须将4A（也可先狭义理解为原业务系统的系统管理模块）和流程引擎下沉到平台层共性建设，或者说优先要将这两个模块作为微服务模块剥离出来，同时给上层的业务组件模块提供API服务接口能力。
　　对于4A模块剥离后，我们希望的是涉及到人员，组织，用户，权限等能力的获取都是通过服务接口实时查询获取，这些基础主数据信息也不要落地。在进行这样实施的时候确实会增加上层业务系统的改造工作量。对于流程平台的签出相对来说比较容易，最主要的还是给业务模块提供流程启动，暂停，获取待办已办列表等关系服务接口信息为主。
　　进行4A和流程平台的剥离核心目的仍然是是的后续需要进行拆分的业务模块只包含业务功能，而不再包含共性的技术能力功能。
　　步骤2：基础主数据模块能力独立建设
　　这是我们谈的第二个重点，即希望将提供共享基础主数据的功能单独剥离出来进行独立建设，比如建设独立的主数据平台或叫提供基础主数据的各个数据中心模块。然后数据能力以数据服务的方式暴露出去供上层业务系统使用，同样我们希望上层业务模块在使用这些基础主数据的时候最好主数据不落地，实时用实时查。
　　在传统PaaS平台建设中会涉及到MDM主数据平台的建设，到了彻底的微服务架构可能并不存在主数据平台的概念，而是各个类似产品中心，供应商中心，客户中心的各个微主数据中心模块，这些微服务模块也是我们常说的中台的核心数据能力提供中心。
　　要规划和建设中台，首先要考虑的就是这种基础数据中心，其次才是提供业务支撑和业务逻辑处理的中心。
　　步骤3：业务模块的拆分到微服务模块或逐步剥离出来
　　我们一直在讲，传统企业的微服务架构转型是一个渐进的过程，是一个老的IT架构逐渐被新架构替换，老架构逐步消亡的过程。在步骤1和步骤2这种共性的基础技术和数据能力下沉后，剩余的业务系统迁移和微服务模块拆分就可以开始逐步进行，逐步迁出。
　　对于一个业务系统的业务模块逐步剥离出来，一个关键的策略就是优先剥离耦合性最低的业务功能模块，在这个思路下最可能的实施策略就是先将业务系统支持流程的两端（最前端流程或最后端流程）逐步剥离出来。因为两端的流程往往是耦合性最小的流程。
　　拿采购系统来举例，前端的招投标模块是最容易剥离出来的，后端的采购过程跟踪，采购评估等模块往往也是最容易剥离出来的。这里拿招投标模块来举例。
　　注意招投标模块在剥离出来后，横向的交互接口往往并不多，最多也就是招投标执行过程的结果信息或配额信息需要传递到采购管理模块。而对于招投标本身的一些结果数据已经可以下沉到平台层的主数据模块中，而设计到流程处理部分也已经下沉到平台层的流程引擎模块，因此可以看到只要步骤1和2迁移到平台层后，再迁移出招投标模块基本就很容易了。
　　步骤4：及早的进行统一门户的建设
　　要注意，在各个微服务模块建设完成后，单个微服务模块本身是不能提供支撑完整业务流程的能力。对于用户来说并不关心是否进行了微服务架构化，而是关心涉及到业务流程处理的功能和操作是否能够很方便的在一个业务应用里面操作和完成。
　　而这些业务模块基于业务流程，基于业务场景和使用部门的组装和展现，就需要在门户层完成。对于统一门户不仅仅是提供统一认证和单点登录，也还包括了统一的待办集成和任务处理，统一的消息通知等共性功能能力。也就是说，只要是各个微服务模块共性的一些需要展现的能力，都可以集中化到统一门户层去集中处理和展现。
　　门户层还有一个重要的功能就是进行微服务模块的组装，这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持，让最终用户的感觉就是在使用一个系统，没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择，也还可以做一些展现层的编排和组合工作。
　　对于微服务模块的灵活组装也是相当困难的，因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接，这往往是比对服务组合和服务编排进行定制更加困难，对于这个问题后续将在单独进行讨论。