『高级篇』docker之微服务架构带来的问题(五)
2019-01-21 15:20:10
李明
  • 访问次数: 379
  • 注册日期: 2018-07-09
  • 最后登录: 2020-03-30

原创文章,欢迎转载。转载请注明:转载自 IT人故事会,谢谢!
原文链接地址: 『高级篇』docker之微服务架构带来的问题(五)

之前已经说了微服务的概念,相信老铁对微服务有了一个深刻的概念,从此以后咱们深入微服务,一步步来分析使用微服务会给我们带来哪些问题,或者说使用微服务需要解决哪些问题,以及微服务在业界的解决方案

微服务架构引入的问题和解决方案

  • 微服务间如何通信的?

可以考虑下,如果是单体架构会不会有这样的问题,在什么情况下服务和服务之间如何通迅,调用什么样的接口,依赖什么样的数据,单体架构这种情况是很少见的,一个系统在一个应用可能已经完成了相应的功能,也不排除一些系统的数据是来此其他的系统的,单体架构的常用的方式有几种,直接链接地址拿过来直接嵌入到页面里面,我们使用httpclient调用对方的接口拿到返回的数据,这是比较常见的方案,微服务要重点考虑,因为微服务他们接口比较多,他们的调用非常的频繁,所以我们必须事先设计好如何快捷高效的微服务通信。

  • 微服务如何发现彼此

单体架构如何发现彼此,用过dubbo的同学应该知道,dubbo其实就是发现一种服务,web端的调用者需要对dubbo的提供者进行一次发现的,发现是通过zookeeper等,类似一个中间人的身份,服务的提供者,提供者告诉中间人。消费者通过中间人拿到提供者的地址,就能够完成服务的发现了。如果是用dubbo直接确定微服务就可以了。但是我们使用的微服务可能涉及到各种语言读取方式,dubbo只限java语言的通信,所以彼此发现是我们需要提前设定和解决的问题。

  • 微服务怎么部署?更新?扩容

还是从单体架构来想,这跟每个公司的方式不同,有的直接通过ftp工具直接把war包上传,执行命令执行重启;有的可能用到了自动部署工具直接从master节点通过jenkens生成war包在准生产服务器指定目录生成,没有问题然后通过脚本的方式,对拷到生产环境。然后重启。如果是微服务不一定少,一个完整的服务可能需要几十来配合修改,如果在一个个手动来进行部署运维人员都崩溃死了。所以微服务的部署更新成为我们要解决的问题。

PS:先抛出问题,然后下次咱们说具体的问题分析。

1240


李明 最后编辑, 2019-01-21 15:21:34