不够痛就不要微服务！传统行业的微服务之路注定比互联网更加艰难！读完文章相信你一定会感同身受。
微服务落地是一个复杂问题，牵扯到IT架构、应用架构、组织架构、流程等多个方面。
在多家传统行业的企业走访和落地了微服务之后，发现落地微服务是一个非常复杂的问题，甚至都不完全是技术问题。
当时想微服务既然是改造应用，做微服务治理，类似注册，发现，熔断，限流，降级等，当然应该从应用开发组切入，一般一开始聊的会比较开心，从单体架构，到SOA，再到微服务架构，从Dubbo聊到SpringCloud，但是必然会涉及到微服务的发布和运维问题，涉及到DevOps和容器层，这些都不在开发组的控制范围内，一旦拉进运维组，对于容器的接受程度就成了一个问题，和传统物理机，虚拟机的差别，会带来什么风险等等等等，尤其是容器绝对不是轻量级的虚拟化这件事情，就不是一时半会儿能说的明白的。更何况就算说明白了，还有线上应用容器，一旦出了事情，谁背锅的问题，容器往往会导致应用层和基础设施层界限模糊，这使得背锅双方都会犹豫不决。
有的企业的微服务化是运维部门发起的，运维部门已经意识到了各种各样不统一的应用给运维带来的苦，也乐意接受容器的运维模式，这就涉及到容器直接的服务发现是否应该运维在容器层搞定，还是应用应该自己搞定的问题，还涉及Dockerfile到底是开发写还是运维写的问题。一旦容器化的过程中，开发不配合，运维单方面去做这个事情，是徒增烦恼却收益有限的。
下图是微服务实施的过程中涉及到的层次，具体的描述参考文章云架构师进阶攻略
在一些相对先进的企业，会在运维组和开发组之间，有个中间件组，或者叫做架构组，来负责推动微服务化改造的事情，架构组就既需要负责劝说业务开发实施微服务化，也要劝说运维组实施容器化，如果架构组的权威性不足，推动往往也会比较困难。
所以微服务，容器，DevOps的推动，不单单是一个技术问题，更是一个组织问题，在推动微服务的过程中，更加能够感觉到康威定律的作用，需要更高层次技术总监或者CIO的介入，方能够推动微服务的落地。
然而到了CIO层，在很多企业又体会不到技术层面的痛点了，而更加关注业务的层面了，只要业务能赚钱，架构的痛，中间件的痛，运维的痛，高层不是非常能够感知，也就体会不到微服务，容器化的技术优势了，而微服务和容器化对于业务的优势，很多厂家在说，能够说到表面，说不到心里。
因而微服务和容器化的改造，更加容易发生在一个扁平化的组织里面，由一个能够体会到基层技术细节的痛的CIO，高瞻远瞩的推动这件事情。这也是为什么微服务的落地一般率先落地在互联网公司，因为互联网公司的组织架构实在太平台，哪怕是高层，也离一线非常的近，了解一线的痛。
然而在传统行业就没有那么幸运了，层级往往会比较多，这个时候就需要技术上的痛足够痛，能够痛到影响业务，能够痛到影响收入，能够痛到被竞争对手甩在后面，才能上达天听。
接下来的几篇文章我们就梳理一下，在这个过程中的那些痛。
