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