开篇：系统改造的调研报告

关于系统的改造探索

开篇：系统改造的调研报告

第一部分——Docker篇

第一章 Docker容器
第二章 Docker安装
第三章 构建自定义镜像
第四章 搭建镜像仓库
第五章 容器编排
第六章 容器监控

---

文章目录

• 关于系统的改造探索
• • • 第一部分——Docker篇
• 前言
• 一、系统现状
• 二、技术调研
• 三、大致构想
• 四、不足和展望
• 总结

---

前言

    随着业务的发展，传统的架构已经不符合项目的要求了。双活、集群也渐渐提上了日程。。。

---

一、系统现状

1. 现在没有专门的运维，开发常常兼职运维的工作，导致无法专心于开发，时间浪费在部署环境、查找问题上

2. 生产上要搭建双活环境。再加上现在已有的集群，动辄几十台机子。所有机子都要安装一遍redis、nginx，这工作量简直不可想象

3. 各个机子的配置，软件版本存在差异，把测试环境的软件包拿过去安装，发现版本对不上，导致安装失败，简直让人崩溃

4. 现在系统已经多达十几个，新老系统交错，各类技术混用。这么对这些系统进行统一管理、服务治理、服务发现也是个很头疼的问题

5. 因为系统多，导致整个调用链路很长，日志分散，之后出现生产问题，无法快速定位问题

6. 现在发布版本，常出现生产问题，虽然有版验环境，但实际上效果不佳，生产需要有灰度环境，以及快速回滚的方式

---

二、技术调研

    针对以上问题，业内也已经有现成的解决方案：

1. 针对开发兼职运维的工作，可以通过CI/CD来实现，开发只需要提交代码，而后自动触发自动部署流程。即开发提交代码到CVS，Jenkins主动拉取最新代码，触发部署流程

2. 对于十几台机子要重复安装环境，这方面也有专门的部署工具，如：Ansible。通过Ansible编写剧本达到部署整个集群的目的

3. 至于环境之间存在差异，可以通过容器化解决，通过Docker来屏蔽系统之间的差异，实现移植的目的

4. 在基于容器化的前提下，不同系统的之间的统一管理、服务治理、服务发现也方便实现了，可以通过k8s和istio进行实现。至于为什么采用服务网格而不是SpringCloud，是因为现有系统不全是SpringBoot项目，有些老项目直接用SSH（ Struts2、Spring，Hibernate），有些甚至更古老，改造起来非常麻烦，风险也大。还有些项目用的是Python实现，这样子SpringCloud就更不适用了。基于以上种种，故而选择服务网格的方式

---

三、大致构想

    开发人员只需要提交代码到CVS，而后由CI/CD工具自动触发编译部署，通过日志平台统一管理日志，Prometheus作系统监控

四、不足和展望

    没有完美的技术方案，都存在利弊，只谈优点，不谈缺点，那是耍流氓。在上述提到的一系列方案中。虽然能简化运维方面的活，但对于开发还是有一定要求的，学习陡峭，全部掌握有一定难度，整套系统不稳定的话，维护成本也很大

---

总结

    这是一次尝试，意在解决现在集群管理麻烦，开发任务重的问题。上述内容笔者也是初次使用，整体思路可能不太成熟，有所欠缺。如果大家有更好的解决方案，不妨告知笔者一下
注：以上提及到的技术后续可能根据实际情况进行调整