云原生(18)：记一次上云原生失败的案例

Posted 2021-04-03 01WORLD

都说云原生商用元年是2019年，到了2020年，很多厂商都在上容器化技术。我们也逐渐开始用云原生，有成功也有失败，其中无奈也只有自知了。今天分享一例失败的案例。

这是一家高校头部应用系统的供应商，采用了微服务架构，并以容器的方式交付。系统开发语言是Java，框架也就选了Spring Boot，并采用Zuul和Eureka来做路由网关和服务注册管理。听起来这是一个云原生标配啊，已经完全做好了云原生交付准备，遂通知对方我们可以配合做好云原生交付。当然，在开发阶段，我们分配了虚拟机装Docker用于测试，待开发完成正式上线前再切换到我们的K8K集群。

一切都很美好。

然而真正要上线时，我们才发现，根本不是那么回事啊。我们惊呆了：

1、Zuul和Eureka的信息都是在配置文件中，而每个配置文件都是打包在Docker镜像中。

2、配置文件中服务信息全是固定IP，也就是分配的虚机IP。

3、微服务有8个多，每个微服务都是独立容器交付，关键是每个容器是靠Docker run手工命令行运行，难怪需要在配置文件里写死IP。

4、部署拓扑结构中有一个负载均衡组件，但实际部署中未见该组件。

以上问题让我们大吃一惊。谨慎起见，我们开会交流了一下。问了几个问题：

1、怎么不用Docker Swarm或者Stack？
答：不知道

2、那你怎么自动启动所有的微服务呢？
答：我们有命令行脚本，一条条启动。

3、配置文件怎么放到镜像里？
答：没问题啊

5、微服务的负载是怎么控制的？
答：这不清楚，里面有配置文件的

6、负载是靠修改配置文件的？
答：问了开发，是的，需要手工修改配置文件

7、日志存到哪里？
答：数据库。

后面还有一个问题我也不愿意再问了：12要素知道吗？Docker Registry怎么处理？

我也不期望他们知道了。

无奈之下，我们就让对方修改配置文件，主机信息放到环境变量里，然后修改成Docker Stack模式，先独立运转一段时间，后续再作迁移。

举这个例子，无意贬低该公司。而是觉得上云原生还有很长的路要走，还需要云原生宣贯，还需要理解云原生的精髓，才能科学合理地使用云原生交付。否则就是形而上学，失去了事物本来的含义。