企业微服务技术架构演进方案.docx

PAGE 2 企业微服务技术架构演进方案  目 录 TOC \o 1-3 \h \z \u 一、微服务落地是一个复杂问题，牵扯到IT架构，应用架构，组织架构多个方面 4 二、阶段一：单体架构群，多个开发组，统一运维组 7 2.1. 阶段一的组织状态 7 2.2. 阶段一的运维模式 8 2.3. 阶段一的应用架构 9 2.4. 阶段一有什么问题吗？ 10 2.5. 什么情况下才会觉得阶段一有问题？ 11 三、阶段二：组织服务化，架构SOA化，基础设施云化 13 3.1. 阶段二的组织形态 13 3.2. 阶段二的应用架构 14 3.3. 阶段二的运维模式 22 3.4. 阶段二有什么问题吗？ 31 3.5. 什么情况下才会觉得阶段二有问题？ 32 四、阶段三：组织DevOps化，架构微服务化，基础设施容器化 34 4.1. 阶段三的应用架构 35 4.2. 阶段三的运维模式 38 4.3. 阶段三的组织形态 42 五、如何实施微服务，容器化，DevOps 45 场景一：架构SOA拆分时，如何保证回归测试功能集不变 48 场景二：架构SOA化的时候，如何统一管理并提供中台服务 50 场景三：服务SOA化的时候，如何保证关键服务的调用安全 51 场景四：架构SOA化后，对外提供API服务，构建开放平台 52 场景五：互联网场景下的灰度发布和A/B测试 53 场景六：互联网场景下的预发测试 53 场景七：互联网场景下的性能压测 54 场景八：微服务场景下的熔断，限流，降级 54 场景九：微服务场景下的精细化流量管理。 55  一、微服务落地是一个复杂问题，牵扯到IT架构，应用架构，组织架构多个方面 在多家传统行业的企业走访和落地了微服务之后，发现落地微服务是一个非常复杂的问题，甚至都不完全是技术问题。 当时想微服务既然是改造应用，做微服务治理，类似注册，发现，熔断，限流，降级等，当然应该从应用开发组切入，一般一开始聊的会比较开心，从单体架构，到SOA，再到微服务架构，从Dubbo聊到SpringCloud，但是必然会涉及到微服务的发布和运维问题，涉及到DevOps和容器层，这些都不在开发组的控制范围内，一旦拉进运维组，对于容器的接受程度就成了一个问题，和传统物理机，虚拟机的差别，会带来什么风险等等等等，尤其是容器绝对不是轻量级的虚拟化这件事情，就不是一时半会儿能说的明白的。更何况就算说明白了，还有线上应用容器，一旦出了事情，谁背锅的问题，容器往往会导致应用层和基础设施层界限模糊，这使得背锅双方都会犹豫不决。 ? ? ?? 有的企业的微服务化是运维部门发起的，运维部门已经意识到了各种各样不统一的应用给运维带来的苦，也乐意接受容器的运维模式，这就涉及到容器直接的服务发现是否应该运维在容器层搞定，还是应用应该自己搞定的问题，还涉及Dockerfile到底是开发写还是运维写的问题。一旦容器化的过程中，开发不配合，运维单方面去做这个事情，是徒增烦恼却收益有限的。 下图是微服务实施的过程中涉及到的层次，具体的描述参考文章 云架构师进阶攻略 ? ? ? ?? ? ?? 在一些相对先进的企业，会在运维组和开发组之间，有个中间件组，或者叫做架构组，来负责推动微服务化改造的事情，架构组就既需要负责劝说业务开发实施微服务化，也要劝说运维组实施容器化，如果架构组的权威性不足，推动往往也会比较困难。 所以微服务，容器，DevOps的推动，不单单是一个技术问题，更是一个组织问题，在推动微服务的过程中，更加能够感觉到康威定律的作用，需要更高层次技术总监或者CIO的介入，方能够推动微服务的落地。 然而到了CIO层，在很多企业又体会不到技术层面的痛点了，而更加关注业务的层面了，只要业务能赚钱，架构的痛，中间件的痛，运维的痛，高层不是非常能够感知，也就体会不到微服务，容器化的技术优势了，而微服务和容器化对于业务的优势，很多厂家在说，能够说到表面，说不到心里。 因而微服务和容器化的改造，更加容易发生在一个扁平化的组织里面，由一个能够体会到基层技术细节的痛的CIO，高瞻远瞩的推动这件事情。这也是为什么微服务的落地一般率先落地在互联网公司，因为互联网公司的组织架构实在太平台，哪怕是高层，也离一线非常的近，了解一线的痛。 然而在传统行业就没有那么幸运了，层级往往会比较多，这个时候就需要技术上的痛足够痛，能够痛到影响业务，能够痛到影响收入，能够痛到被竞争对手甩在后面，才能上达天听。 我们接下来就梳理一下，在这个过程中的那些痛。  二、阶段一：单体架构群，多个开发组，统一运维组 ? ??? ? ??