原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『高级篇』docker之微服务架构带来的问题（五）之前已经说了微服务的概念，相信老铁对微服务有了一个深刻的概念，从此以后咱们深入微服务，一步步来分析使用微服务会给我们带来哪些问题，或者说使用微服务需要解决哪些问题，以及微服务在业界的解决方案
微服务间如何通信的？
可以考虑下，如果是单体架构会不会有这样的问题，在什么情况下服务和服务之间如何通迅，调用什么样的接口，依赖什么样的数据，单体架构这种情况是很少见的，一个系统在一个应用可能已经完成了相应的功能，也不排除一些系统的数据是来此其他的系统的，单体架构的常用的方式有几种，直接链接地址拿过来直接嵌入到页面里面，我们使用httpclient调用对方的接口拿到返回的数据，这是比较常见的方案，微服务要重点考虑，因为微服务他们接口比较多，他们的调用非常的频繁，所以我们必须事先设计好如何快捷高效的微服务通信。
微服务如何发现彼此
单体架构如何发现彼此，用过dubbo的同学应该知道，dubbo其实就是发现一种服务，web端的调用者需要对dubbo的提供者进行一次发现的，发现是通过zookeeper等，类似一个中间人的身份，服务的提供者，提供者告诉中间人。消费者通过中间人拿到提供者的地址，就能够完成服务的发现了。如果是用dubbo直接确定微服务就可以了。但是我们使用的微服务可能涉及到各种语言读取方式，dubbo只限java语言的通信，所以彼此发现是我们需要提前设定和解决的问题。
还是从单体架构来想，这跟每个公司的方式不同，有的直接通过ftp工具直接把war包上传，执行命令执行重启；有的可能用到了自动部署工具直接从master节点通过jenkens生成war包在准生产服务器指定目录生成，没有问题然后通过脚本的方式，对拷到生产环境。然后重启。如果是微服务不一定少，一个完整的服务可能需要几十来配合修改，如果在一个个手动来进行部署运维人员都崩溃死了。所以微服务的部署更新成为我们要解决的问题。
PS：先抛出问题，然后下次咱们说具体的问题分析。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
