转载

传统企业转型对微服务架构的诉求(12.3)

传统企业在转型过程中，对微服务架构的诉求究竟在哪里？在前面很多文章里面我们都做过分析，企业转型到微服务架构实际上是增加了企业的IT治理和管控难度，如果企业本身的IT治理成熟度不够往往遇到的问题更大。那么传统企业或者有一定信息化基础的企业朝微服务架构转型的动力究竟在哪里？

采用微服务架构，仅仅是引入一种新的开发框架，将传统的单体应用转化为组件化和服务化的架构模式，或者说当前IT架构设计和开发流行微服务架构？感觉很多企业一股脑的上微服务架构，确实存在不少的企业为什么要转型，为什么要实施微服务架构没有想清楚，自身的IT成熟度也没有评估，为了流行或趋势而在不恰当的时间点实施微服务架构，本身就是一种激进的表现。

那么微服务架构转型，企业的真实诉求究竟有哪些？通过微服务架构实施究竟能够解决哪些问题？

在前面很多文章里面我都提到了，微服务架构思想带来一个关键点，不仅仅是组件化和服务化开发， 更加重要的是平台+应用的构建模式，同时这个应用本身就是能够通过松耦合的微服务模块灵活组装和构建的 。这个是转型带来的一个巨大好处，就是传统的一个业务系统的开发模式不存在的了，取而代之的是单独的业务组件或业务模块的开发，通过共性平台层服务能力的支撑，我们不再需要开发重复的类似流程引擎，4A，公共技术组件等这些内容，而只需要将开发重心真正专注到业务功能和逻辑实现上。

有时候我们谈微服务架构就会谈到解耦，但是你微服务模块划分的越细，那么这些模块之间的集成往往更加复杂，再加上很多API接口本身就是同步实时调用模式实现，导致的不是模块高度直治，反而是对外部基础平台或业务组件的依赖更大。

即微服务架构化后，微服务模块间的集成复杂度增加了，如果模块划分的不合理，那么耦合性往往更强。

那么将单体应用划分为微服务模块，除了复用基础平台能力外，还有啥好处？ 这个好处最重要的就是我们管理的单位和管理的粒度更小的，对于后期的IT运维和变更处理更加方便 。这种方便性体现在业务模块的性能扩展，也体现在业务模块的功能和业务变更重新部署和发布。你会发现这些事务的影响比原来更加小。比如一个微服务模块变更，如果其接口没有变化而是内部逻辑变化，那么我们只需要对该模块进行变更，并只对该模块进行测试和发布即可，而不会影响到其它的业务功能组件和模块。同时在微服务架构下，我们更加容易实现微服务模块的动态热部署，在和容器技术结合后更加容易实现动态资源弹性扩展。

提升甲方对整个IT应用的过程管控能力始终都是我认为的微服务架构实施后带来的一个重大好处 ，即原来是一个大的业务系统开发，那么业务系统内部开发商过程如何管控，质量如何，内部组件接口是否设计能力，该暴露的能力是否暴露，这些内容对甲方来说都是黑盒，根本就无法展开有效的过程和质量管控。而在实施微服务架构后最大的好处就是甲方的管控粒度细化到微服务模块，即真正打开原来开发商的内部黑盒，可以细化管理到每个模块的交付，接口，过程质量，这带来的是一个重大的甲方管控能力提升。

由于单体应用被拆分，强势的甲方还可以提前制定好微服务架构开发框架和模式，引入DevOps过程和方法论，同时引入多个开发商来共同开发多个微服务模块，真正将开发过程可视化，持续集成过程可视化，由事后的验收和质量控制转变为过程中的随时管控，真正避免后期被单一开发商绑架的问题。

自动化一定是微服务架构实施的另外一个受益点 ，这个自动化包括了DevOps过程自动化，也包括了后期运维监控，变更发布过程的自动化。如果一个微服务架构实施没有能够实现自动化，反而投入了更多的人力资源来实现过程管控，后期的运维监控，那么微服务架构实施的初衷都没有达到，不仅仅是增加了开发运维工作量，同时也增加了整体运维和管控的难度。当然这个自动化的实现，一个是涉及到开发商的能力水平，同时本身也涉及到甲方本身的信息化经验和成熟度，两者缺一不可。

互联网各种最佳实践相对多，一定要意识到有些东西在短时间并不适合马上应用到传统企业。这不仅仅是IT能力方面的问题，也涉及到业务模式和管控本身的差异。

微服务架构下是我们前面谈过的SOA关键思想的落地，即真正实现业务能力组件化和组件能力服务化，同时实现前端应用的可组装化，只有这样才可能真正搭建灵活的SOA架构，实现当前IT架构对业务变化，新业务模式开展下的快速响应和支撑能力。

快速响应并灵活的支撑业务，是微服务架构带来的另外一个关键业务价值实现。

原文 http://blog.sina.com.cn/s/blog_493a84550102yjno.html

正文到此结束