背景

我们项目开始使用了微服务springcloud alibaba，每个服务都有多个实例，刚开始用脚本手动部署，实在是麻烦。

后来决定上k8s来解决此问题，k8s是什么我这里就不展开说了。我这里主要说怎么用k8s来解决部署的问题的。

springcloud里面的概念k8s里大部分都有可以替换的方案了，比如配置中心，注册中心，客户端调用服务的时候负载均衡等。

痛点：

如果在springcloud的项目中，配置中心，注册中心等都去用k8s的，那实际工作对于我们会有一些问题

1. 开始过程中调试问题，因为用了k8s，服务与服务之间的调用都依赖了k8s，所以如果开发者想自己在本地测试，那么必须自己在本地搭建k8s环境来进行相关的测试。给开发者带来了不方便。
2. 用了k8s后，springcloud里面的网关就没法用了，k8s的ingress跟springcloud里面的网关比功能还是弱，springcloud里面的网关是可以自己写代码实现相关功能的，比如统一鉴权，统一日志，统一加解密等，k8s的ingress只是数据流量的入口，实现不了这些功能。
3. springcloud alibaba有个组件sentinel，流量控制，熔断降级都很好用，k8s里面没有这个功能，istio虽然有这个功能，但是第一它的这个功能没有目前sentinel好用成熟，第二它的这块代码直接在平台层实现了，对于我们是个黑盒子不可控，所以istio也不敢用。

总的来说，k8s里面微服务相关的功能都不够成熟而且也不易用，开发阶段调试困难，导致我们在配合k8s的时候比较谨慎，那k8s怎么和springcloud配合呢？且看我们的方案

k8s和springcloud配合

既然知道了k8s的不足之处，我们最终的方案就是：

k8s只是用来部署springcloud，其他的功能都还用springcloud自身的，比如注册中nacos，网关gateway，限流降级sentinel等。k8s在我们项目中只是用来进行容器化部署，弹性伸缩的。

具体实施方案

上图就是我们的部署方案。

其中订单服务，商品服务，网关直接用k8s的Depolyment组件去构建而没有去用k8s的Service。

注册中心用的是nacos，部署在k8s外部，当然也可以部署在k8s内部。

数据库也部署在k8s外部，在我们架构中只是把springboot部分应用实例部署到了k8s中，因为这部分是开发中修改最多的，也是部署频率最频繁的，所以放到k8s中很有必要。

数据库一般都有自己的集群方案，而且数据库扩容比较复杂的是数据的平衡，用k8s管理个人认为加大了集群管理的复杂度。

nacos本身部署频率也不高，所以我们也放到了k8s外部。

ingress统一入口

访问的入口我们用了ingress-nginx，用它的好处是它管理了入口流量，网关部分可以通过k8s弹性扩容，然后ingress可以实现负载均衡的去访问各网关实例。

如果不用ingress也可以，这个时候需要你把网关暴露出去，然后在k8s外部用nginx，这样的缺点是网关增加实例数量，需要修改nginx配置。如果用ingress-nginx就没有此问题了。

需要注意一点的是网关服务，除了向nacos注册，调用内部应用外，还需要使用k8s的Service组件，来供ingress内部去负载均衡的调用网关实例。

总结

我们的方案使用springcloud全部组件和特性，对开发者开发调试更容易，开发方式也更熟悉。部署的时候只需要部署应用部分，发挥k8s部署扩容方便的优势。结合了两者共同的优势

--后面我会跟大家讲，我工作中更多实战的东西，希望大家多多关注