这个问题和是否在容器没有任何的关系,不在容器里面也应该考虑这些问题吧
我们集成了apm来做故障发现和排查,可以通过查询容器在哪台宿主机上,然后抓指定虚拟网卡上容器的网络包
优先考虑公司整个网络扁平化,互联互通,这样对应用改造成本要小很多,即基于公司原来的网络打通来进行,如果容器的应用是一个相对独立的服务,可以考虑overlay。规模不大的情况下一些开源网络组件可以考虑采用
上下文路径的问题,/opt/ 2019double下面的文件肯定大小不一样啊
跨语言的微服务框架有维护成本高的问题,一般同一个公司有多种语言的存在,建议使用下一代的微服务技术-service mesh,彻底解决跨语言的问题
微服务与容器的关系是比较密切的,微服务运行实体其实是进程-服务,恰好与容器的单进程模型吻合,再加上容器能保证环境的一致性,加速部署效率,能有效的减轻运维成本,因此容器化是微服务的一个比较好的实践。
ESB的功能比服务注册发现中心多的多,他更强调的是服务的复用和互操作,因此除了注册发现这些功能外,还包括了编排,消息转换,安全管理,消息发布订阅,甚至带有业务建模的功能。
初期建议以业务维度来拆分,微服务并没有一个非常明确的拆分原则,要根据实际情况来把握
1.可以采用演进的方法改造老旧应用,先拆分相对独立的部分,变化很频繁的部分。 2.可以采用绞杀的方式来改造老旧应用,采用新技术开发接口,与老旧应用共存,逐步替换 挑战的话:数据一致性的问题,服务运维的问题,与原有基础
微服务架构在实践中必然触及组织架构架构调整和管理模式的调整,构建微服务体系,需要整个配套设施的支持(变更流程,监控,资源管理,测试,版本管理,服务注册与发现,配置管理,日志,服务治理)涉及方方面面
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30