致传统企业朋友：不够痛就别微服务，有坑

应用层需要处理这十二个问题，最后一个都不能少，实施微服务，你做好准备了吗？你真觉得攒一攒SpringCloud，就能够做好这些吗？

4.2. 阶段三的运维模式

到了微服务阶段，实施容器化之后，你会发现，然而本来原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？

这就不是技术问题了，其实这就是devops，DevOps不是不区分开发和运维，而是公司从组织到流程，能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。

其实开发和运维变成了一个融合的过程，开发会帮运维做一些事情，例如环境交付的提前，Dockerfile的书写。

运维也可以帮助研发做一些事情，例如微服务之间的注册发现，治理，配置等，不可能公司的每一个业务都单独的一套框架，可以下沉到运维组来变成统一的基础设施，提供统一的管理。

实施容器，微服务，DevOps后，整个分工界面就变成了下面的样子。

在网易就是这个模式，杭州研究院作为公共技术服务部门，有运维部门管理机房，上面是云平台组，基于OpenStack开发了租户可自助操作的云平台。PaaS组件也是云平台的一部分，点击可得，提供SLA保障。容器平台也是云平台的一部分，并且基于容器提供持续集成，持续部署的工具链。

微服务的管理和治理也是云平台的一部分，业务部门可以使用这个平台进行微服务的开发。

业务部门的中间件组或者架构组合云平台组沟通密切，主要是如何以正确的姿势使用云平台组件。

业务部门分前端组，业务开发组，中台开发组。

五、如何实施微服务，容器化，DevOps

实施微服务，容器化，DevOps有很多的技术选型。

其中容器化的部分，kubernetes当之无愧的选择。但是Kubernetes可不仅仅志在容器，他是为微服务而设计的。对于实施微服务各方面都有涉及。

详细分析参加为什么 kubernetes 天然适合微服务  但是Kubernetes对于容器的运行时生命周期管理比较完善，但是对于服务治理方面还不够强大。

因而对于微服务的治理方面，多选择使用dubbo或者springCloud。使用Dubbo的存量应用比较多，相对于Dubbo来讲，SprinGCloud比较新，组件也比较丰富。但是SpringCloud的组件都不到开箱即用的程度，需要比较高的学习曲线。

因而基于Kubernetes和SpringCloud，就有了下面这个微服务，容器，DevOps的综合管理平台。包含基于Kubernetes的容器平台，持续集成平台，测试平台，api网关，微服务框架，APM应用性能管理。

       主要为了解决从阶段一到阶段二，或者阶段二到阶段三的改进中的痛点。

下面我们列举几个场景。

场景一：架构SOA拆分时，如何保证回归测试功能集不变

前面说过，服务拆分后，最怕的是拆完了引入一大堆的bug，通过理智肯定不能保证拆分后功能集是不变的，因而需要有回归测试集合保证，只要测试集合通过了，功能就没有太大的问题。

回归测试最好是基于接口的，因为基于UI的很危险，有的接口是有的，但是UI上不能点，这个接口如果有Bug，就被暂时隐藏掉了，当后面有了新的需求，当开发发现有个接口能够调用的时候，一调用就挂了。

       有了基于Restful API的接口测试之后，可以组成场景测试，将多个API调用组合成为一个场景，例如下单，扣优惠券，减库存，就是一个组合场景。

另外可以形成测试集合，例如冒烟测试集合，当开发将功能交付给测试的时候，执行一下。再如日常测试集合，每天晚上跑一遍，看看当天提交的代码有没有引入新的bug。再如回归测试集合，上线之前跑一遍，保证大部分的功能是正确的。

场景二：架构SOA化的时候，如何统一管理并提供中台服务

当业务要提供中台服务的时候，中台服务首先希望能够注册到一个地方，当业务组开发业务逻辑的时候，能够在这个地方找到中台的接口如何调用的文档，当业务组的业务注册上来的时候，可以进行调用。

在微服务框架普通的注册发现功能之外，还提供知识库的功能，使得接口和文档统一维护，文档和运行时一致，从而调用方看着文档就可以进行调用。

另外提供注册，发现，调用期间的鉴权功能，不是谁看到中台服务都能调用，需要中台管理员授权才可以。

为了防止中台服务被恶意调用，提供账户审计功能，记录操作。

场景三：服务SOA化的时候，如何保证关键服务的调用安全         

有的服务非常关键，例如支付服务，和资金相关，不是谁想调用就能调用的，一旦被非法调用了，后果严重。

在服务治理里面有路由功能，除了能够配置灵活的路由功能之外，还可以配置黑白名单，可以基于IP地址，也可以基于服务名称，配置只有哪些应用可以调用，可以配合云平台的VPC功能，限制调用方。

场景四：架构SOA化后，对外提供API服务，构建开放平台

架构SOA化之后，除了对内提供中台服务，很多能力也可以开放给外部的合作伙伴，形成开放平台。例如你是一家物流企业，除了在你的页面上下单寄快递之外，其他的电商也可以调用你的API来寄快递，这就需要有一个API网关来管理API，对接你的电商只要登录到这个API网关，就能看到API以及如何调用，API网关上面的文档管理就是这个作用。

另外API网关提供接口的统一认证鉴权，也提供API接口的定时开关功能，灵活控制API的生命周期。

场景五：互联网场景下的灰度发布和A/B测试

接下来我们切换到互联网业务场景，经常会做A/B测试，这就需要API网关的流量分发功能。

例如我们做互联网业务，当上一个新功能的 时候，不清楚客户是否喜欢，于是可以先开放给山东的客户，当Http头里面有来自山东的字段，则访问B系统，其他客户还是访问A系统，这个时候可以看山东的客户是否都喜欢，如果都喜欢，就推向全国，如果不喜欢，就撤下来。

场景六：互联网场景下的预发测试

这个也是互联网场景下经常遇到的预发测试，虽然我们在测试环境里面测试了很多轮，但是由于线上场景更加复杂，有时候需要使用线上真实数据进行测试，这个时候可以在线上的正式环境旁边部署一套预发环境，使用API网关将真实的请求流量，镜像一部分到预发环境，如果预发环境能够正确处理真实流量，再上线就放心多了。

场景七：互联网场景下的性能压测

互联网场景下要做线上真实的性能压测，才能知道整个系统真正的瓶颈点。但是性能压测的数据不能进真实的数据库，因而需要进入影子库，性能压测的流量，也需要有特殊的标记放在HTTP头里面，让经过的业务系统知道这是压测数据，不进入真实的数据库。

这个特殊的标记要在API网关上添加，但是由于不同的压测系统要求不一样，因而需要API网关有定制路由插件功能，可以随意添加自己的字段到HTTP头里面，和压测系统配合。

场景八：微服务场景下的熔断，限流，降级

微服务场景下，大促的时候，需要进行熔断，限流，降级。这个在API网关上可以做，将超过压测值的流量，通过限流，拦在系统外面，从而保证尽量的流量，能够下单成功。

在服务之间，也可以通过微服务框架，进行熔断，限流，降级。Dubbo对于服务的控制在接口层面，SpringCloud对于服务的管理在实例层面，这两个粒度不同的客户选择不一样，都用Dubbo粒度太细，都用SpringCloud粒度太粗，所以需要可以灵活配置。

      场景九：微服务场景下的精细化流量管理。

在互联网场景下，经常需要对于流量进行精细化的管理，可以根据HTTP Header里面的参数进行分流，例如VIP用户访问一个服务，非VIP用户访问另一个服务，这样可以对高收入的用户推荐更加精品的产品，增加连带率。

本文转自 ：刘超的通俗云计算。