关键诉求
微服务架构这个概念出来也有2-3年的时间了，从最开始在互联网企业的广泛应用，到现在越来越多的企业开始关注和希望尝试使用微服务架构。在前面的博客文章里面我也专门谈到过对于传统企业如何进行微服务架构转型，包括从哪些小的地方开始切入等。
对于企业从传统it架构到微服务架构的转型，绝对不是盲目的跟风互联网企业，而是企业的业务规范，企业的信息化水平和it成熟度发展到一定阶段后的比如诉求，那么这些关键的诉求究竟有哪些？
从系统规划建设期到it管控治理和运维期
首先可以看到当企业的信息化和it系统建设发展到一定阶段后，自然会从it系统的规划和建设期发展到后期的it系统管控治理和运维期。到了后期不会再有大量的新系统规划建设，而更多的都是为了业务流程优化进行的it系统需求变更，优化和功能改造。那么关键的问题就变成了如何快速的响应业务需求变化并发布系统，同时如何又以最小的代价和影响来发布系统？
传统的it架构模式可以看到很难解决这个问题，每次需求或功能变更的发布周期相当长，同时由于是一个大单体应用全部发布，往往增加了一个新功能反而导致多个老功能出问题。这些都是我们经常遇到的问题，其核心的原因就是原来我们管理的业务系统本身的颗粒度太大了，其次就是从需求到开发到测试到发布整个过程如何自动化衔接。第一点涉及到微服务架构，第二点涉及到paas和devops方面的内容。
在微服务架构下，我们管理的单位从原来的大单体应用变化为了细粒度的微服务模块，自然在变更和发布的时候影响单位也相应变小到各个业务模块粒度。这将有效的解决子在后期运维变更功能发布的影响。
从业务组织和it系统紧耦合到解耦需求
其次，在传统it系统规划和建设中，在企业架构规划设计中，我们经常谈业务和流程驱动it，强调端到端流程的贯通。但是系统规划设计和实现的过程中，最普遍的现象就是不是业务驱动it，而是业务部门驱动it，导致我们的it系统和业务部门是紧耦合的。举例来说，一个企业只有供应链部，那么建设的系统就是供应链系统；但是如果一个企业有采购部，有物流部，那么建设完成的系统就是采购系统和物流系统。
在这种情况下，带来的最大问题就是企业的业务组织架构一调整，往往带来it系统巨大的调整工作量，在我原来的企业也经常遇到it系统经常配合业务组织架构调整的事情。这类工作已经不是简单的hr系统组织结构调整，还包括了本身的业务系统中业务功能点的调整，已有的业务数据的调整，这些都需要进行动态切换和割接。
当企业建设的业务系统越多，和业务部门关系绑定的越紧密，这种调整带来的复杂度和工作量也就越大。
而真正的解决思路就是要将业务部门和业务系统解耦，如何解耦？仍然是从业务流程驱动的角度去考虑和拆分具体的业务单元，这些业务单元形成独立的业务组件（微服务架构中的微服务模块），由于这些业务组件粒度已经足够细，因此更加容易灵活的组装或组合去满足实际业务部门的日常业务需求。
举例来说：如果是大的供应链部门，就配置供应商管理，物料管理，采购订单，招投标，库存管理，物流配送管理等多个微服务模块。如果是拆分为采购部门和物流部门，那么采购部门配置供应商管理，物料管理，采购订单，招投标管理，物流部门配置库存管理，物流配送管理等微服务模块。
在规划和拆分微服务模块的时候更多是业务和流程角度出发，只要划分的足够合理，就能够最小化的减小业务组织架构调整对it系统本身造成的影响。
从单打独斗信息孤岛到共享思路下的平台战略
企业信息化发展到一定阶段，自己都会意识到按照传统的一个个孤立的业务系统建设模式越来越行不通，这不仅仅是业务系统很多功能重复建设的问题，同时还导致了业务系统中数据不一致性，集成困难，后续的运维和变更处理困难等一系列问题。即典型的钱花的更多，但是系统却越来越复杂和难用。
而解决这个问题的的关键就是平台战略，对于平台战略本身又有两个重要的核心，即不是简单的遗留系统能力直接服务化共享，而是首先要集中，其次才是共享。集中化是云的思路，而共享才是soa的思路，两个关键点都解决了才是云计算+soa的关键思路融合。
为啥要把这个问题在微服务架构里面谈，因为平台+应用构建模式本身也是微服务架构实施的一个基础条件，微服务模块更多都应该是独立承担某个业务域的业务组件模块，而不应该包括类似流程引擎，系统管理等共性底层组件，否则微服务模块又变成很重的单体应用，没有了任何价值。
要做好微服务架构，我们就必须做好底层基础共性平台的建设，只是微服务架构里面会谈为共性的技术服务能力提供，都是一个道理，就是共性的东西或能力要下沉，然后再以标准的服务接口方式暴露或共享出来给上层的业务系统使用。
资源池的有效利用和资源动态调度
这是微服务架构结合paas容器化技术和动态调度技术后带来的一个新的亮点，即可以真正实现按照业务需求和业务并发量动态的申请和分配资源，以满足业务并发访问的需求。在整个过程中不需要人为去干预，而只需要设置好相应的调度规则和资源动态扩展规则即可。
对于这个点实际当前并不是很强企业的诉求，只是后续成熟度发展到一定阶段后带来的亮点功能，真正解决了it系统的灵活资源分配，扩展和动态调度问题。
问题解决
企业从传统架构转型到微服务架构后可以解决的问题点或潜在的收益。
进一步节约it基础设施建设投入，容器比虚拟机更加轻量化，同时结合kubernate后可以实现自动化的资源调度，可以最大限度的提升资源的利用率。要明白，没有真正实现paas层能力的企业云平台，往往仅仅是简单的实现了从物理机到虚拟机的使用转变，而并没真正解决资源利用率大幅提升的问题。要解决资源利用率的大幅提升就必须实现应用托管和资源动态调度，而是要非人为干预全部自动化完成。
彻底贯彻平台+应用，以及业务部门和it系统解耦的思想，以后企业扩展的都不再是业务系统，而是业务组件或模块，同时逐渐不再有业务系统的概念，只有业务组件模块的概念。业务部门不会和it系统严格一一对应，而是通过业务组件的组合和组装来类似积木化方式搭建业务部门需要的功能。这是it系统能够更加灵活或柔性的适应企业业务流程，企业组织架构变化的关键一步。
进一步加强企业作为甲方的时候，对业务系统开发厂商的管控能力，即从粗粒度的业务系统管控到更加细粒度的微服务模块。同时结合devops可以使整个从需求，开发，测试，上线的整个过程全部透明化，而不是作为开发商的黑盒。正是由于整个过程的全程可视和自动化，甲方企业才可能后续真正做到业务系统的接维。
敏捷的响应业务变化的能力增强了，你会看到从业务部门提出业务需求或变更，到最终功能发布的上线时间会大大缩短。这种缩短的原因体现在整个流程中能够自动化的工作，全部自动化掉了，包括打包，自动化的单元测试，环境迁移和部署等；其次变更发布影响的范围减小，从影响一个业务系统变化到往往只需要影响一个微服务模块，大大减少了变更发布的测试验证工作量。最后，理想状态下很多平台层的能力和技术服务都全部实现，而实现业务组件的开发只需要关注业务本身，而不需要再去考虑任何技术层的共性能力，这本身也可大大提示业务组件和模块的开发效率。
在整个微服务基础框架+技术服务组件建设完成后，实际上单个业务微服务模块开发本身反而更加容易，在这种情况下微服务模块的开发人员并不需要完整的了解详细的完整业务流程细节。而只需要按业务需求开发业务功能和实现业务逻辑，消费微服务api接口，并按要求提供和暴露共享接口即可。对于微服务模块的集成和组装可以由专门的技术架构人员来完成。
进一步提升企业对it资产的管理水平，企业管理的不再是简单的最终便也部署包，而是实现从最开始的需求到源代码文件的全流程管理和检查。
当企业所有应用都按照标准的微服务架构，开发工具和环境进行开发后，同时严格实施devops后，可以看到企业的运维就完全实现统一管控和运维。包括运维管理流程，运维工具，运维监控和预警等，安全管理等都可以进行统一。同时在这种运维能力统一并自动化后，it运维人员效率提升，需要的it运维人员数量也大幅减少。
厚服务层（领域服务能力下沉）概念，真正实现了前端应用和后端服务的解耦和分离，服务可以更加灵活的组合和组装来构建前端应用。同时可以支撑移动app，bs网页，pad等多种前端应用类型。也可以更加灵活的支撑不同的前端业务应用使用相同可共享的业务服务或技术服务能力。
从传统偏重的esb服务总线集成模式转变到轻量的去中心化的微服务网关集成模式，真正实现整个架构搭建中无中心化节点（也就是无关键瓶颈节点），从而实现整个架构极强的资源动态水平弹性扩展能力。另外从传统的代码编译和部署包交付模式转变为基于docker容器的镜像交付模式，极大的提升了部署和环境迁移的效率，同时提升了整个业务系统的弹性可伸缩性。
实施难点
数据库的拆分
如果数据库没有拆分而仅仅是应用组件拆分不能称为完整意义上的微服务架构，传统单体应用转变为微服务架构后，从页面前端到逻辑层到数据库都应该完全独立的一套，可以独立进行需求，设计，开发，部署和后续的运维管理。因此要转为微服务架构，首先数据库要拆分，微服务模块在拆分的时候一定要考虑对应数据库拆分的合理性和自治性。
数据库拆分后，原来简单的底层数据库关联查询，变化为需要通过领域服务层进行服务组合才能够完成。原来数据库层很容易控制的数据库事务，转变为了由于进行ws接口交互带来的分布式事务问题。这个我们在谈组件化和微服务架构的时候多次谈到，是微服务架构实施的一个关键难点。
其次，基础平台层和技术服务能力的建设是转型中第二个难点
这些能力有可能在传统架构建设模式下已经独立建设，如何将这些共性能力抽象出来并下沉到平台层共性建设，并再将能力以ws接口方式开放出去供上层微服务模块使用，是微服务架构转型中必须首先考虑实施的内容。
要实施这点，就会造成原有业务模块的较大改造，特别是对于原有各业务系统中的技术组件本身差异就大的情况下，这种统一往往更加困难，势必对已有的业务系统造成较大的影响。这也是很早我们在谈企业微服务架构实施策略中谈到的尽量是逐步迁移，老系统或平台也逐步消亡的渐进模式实施。
新技术的引入，微服务架构思想的引入
对于微服务架构，前面已经强调过多次不仅仅是单纯的微服务开发框架的引入，更加重点的是和容器化技术，和devops实践的结合，进一步对组件化架构和领域建模思想的实践，同时可能还涉及到eda事件驱动架构方面的内容。在业务层面还涉及到如何去更好的划分微服务模块，这个粒度究竟如何把控，对于划分完成的微服务模块如何去识别和定义微服务接口，确保接口本身的复用性和粗粒度特性。
因此不是使用了ws接口就是soa，也绝对不是简单的使用了rest接口，使用了spring cloud等微服务框架就是微服务架构。更加重要的是组件化和服务化，持续集成和devops等思想的最终实践和落地。只有这些思想真正落地，才能够解决我在上篇文章中谈到的关键诉求说描述的问题。
企业本身的软件过程成熟度
如果一个企业原来就实施了组件化开发，或者原来就使用了一些开源了soa总线或服务网关产品，已经实践过了持续集成方法论，或者已经建立了自己的类似流程引擎，4a等基础技术平台，那么实施微服务架构相对就很容易。反之，如果一个企业在传统it架构下都没有形成标准的开发过程，开发框架，技术组件积累，标准软件生命周期，编码规范和接口使用标准等，那么要实施微服务架构就相对难。
其次对于微服务架构下，我们管理的最小单位将从原来的一个大的单体应用变化为多个更加细粒度的微服务模块，原来单体应用内部的接口和集成可能属于混乱状态，但是在黑盒内部没有暴露出来，但是事实微服务架构后这些都会被完全暴露出来需要去管控。我们需要管理的微服务模块数量，接口数量等都会成倍的增加，没有一定的it管控和治理流程的积累，要做好这些管控也是相当困难的事情。
最后谈下运维监控能力差距
由于要管理的模块数和接口服务数都成倍的增加，对管控和运维的能力要求都相应提升，如果还按照传统的人工去运维的方式肯定行不通。这里面一方面就是要实现自动化的监控和运维能力，模块和接口服务的性能分析和及时预警能力；其次就是要实施devops，真正将从需求开始，到设计，开发，测试，部署的全过程实现流水线式作业。
可以看到，对当�...