一、问题背景介绍
随着公司的发展；势必要跟随时代的脚步向微服务、容器化方向转型；然而转型过程中势必得遵循服务的迭代替换的方式(一刀切带来的风险太大了)；从而衍生出来虚机和容器中的服务进行注册发现通信的问题。
二、思路&解决方案
一张图胜过千言万语吧；当然最终还是将虚机中的服务全都转到容器中进行统一管理以及对应的弹性伸缩会更加方便一些。
三、解决过程
3.1.先结合自己的理解绘制了初版网络图(第一步的猜想)
3.2.结合自己的猜想进行了各种查询；以及和运维的大佬进行了交流
3.3.最终完善并进行了验证
四、总结
- 4.1.对自己本次问题解决的思路是否正确？对应方案是否可行？是否还有更好方案？
虚机和容器的交互只是一个过度方式；最终还是将虚机中的服务全都转到容器中进行统一管理以及对应的弹性伸缩会更加方便一些 - 4.2.针对于这个问题，扩展到的其它问题，以及后面遇到之后如何落地？
- 4.2.1.运维方面的网络通信知识需要再深入学习
- 4.2.2.k8s网络实现原理进行了简单的了解，后续还应进行更加深入的了解和实践
- 4.3.深入思考自己为什么会遇到这个问题？
技术和公司发展的必经之路；从现在看来，后续再进行新产品服务架构设计的时候定位就直接放到容器化、微服务等会节省很多的事情；庆幸公司有了这次经历也将这个要求列到了规范里面。 - 4.4.画图，博客中要有导图或者流程图
本次博文没想到需要画的导图
五、升华
- 5.1.针对于底层jdk或者其它源码的解读调研
- 5.1.2.k8s网络插件原理？https://network.51cto.com/art/201908/601109.htm
- 5.2.查一查对应官网这样定义规则的意义和目的
- 5.2.1.https://kubernetes.io/zh/ 自己去宏观了解官网了。
- 5.3.在了解其所以然的过程中找到兴趣和提升自己的点
- 5.3.1.过程中和运维大佬的思想碰撞
- 5.3.2.在查资料过程中，以及宏观查阅相关资料过程中给自己的认知上的突破还是很大的
- 5.3.3.给领导和其他团队进行汇报的过程中也产生了很多的交流；那种思维碰撞带来的感觉也是很不错的
