liufengyi

这个问题和是否在容器没有任何的关系，不在容器里面也应该考虑这些问题吧

我们集成了apm来做故障发现和排查，可以通过查询容器在哪台宿主机上，然后抓指定虚拟网卡上容器的网络包

优先考虑公司整个网络扁平化，互联互通，这样对应用改造成本要小很多，即基于公司原来的网络打通来进行，如果容器的应用是一个相对独立的服务，可以考虑overlay。规模不大的情况下一些开源网络组件可以考虑采用

上下文路径的问题，/opt/  2019double下面的文件肯定大小不一样啊

跨语言的微服务框架有维护成本高的问题，一般同一个公司有多种语言的存在，建议使用下一代的微服务技术-service mesh，彻底解决跨语言的问题

微服务与容器的关系是比较密切的，微服务运行实体其实是进程-服务，恰好与容器的单进程模型吻合，再加上容器能保证环境的一致性，加速部署效率，能有效的减轻运维成本，因此容器化是微服务的一个比较好的实践。

ESB的功能比服务注册发现中心多的多，他更强调的是服务的复用和互操作，因此除了注册发现这些功能外，还包括了编排，消息转换，安全管理，消息发布订阅，甚至带有业务建模的功能。

初期建议以业务维度来拆分，微服务并没有一个非常明确的拆分原则，要根据实际情况来把握

 1.可以采用演进的方法改造老旧应用，先拆分相对独立的部分，变化很频繁的部分。  2.可以采用绞杀的方式来改造老旧应用，采用新技术开发接口，与老旧应用共存，逐步替换 挑战的话：数据一致性的问题，服务运维的问题，与原有基础

微服务架构在实践中必然触及组织架构架构调整和管理模式的调整，构建微服务体系，需要整个配套设施的支持(变更流程，监控，资源管理，测试，版本管理，服务注册与发现，配置管理，日志，服务治理)涉及方方面面