微服务架构入门,一些具有代表性的问题

2020-05-22 00:00:00 微服 服务 容器 组件 提供者
昨天收到一封合作客户的邮件,提了一些关于微服务的问题,要求解答。

看了一下,觉得这些问题比较有代表性,很多准备开始做微服务架构的企业或个人都有类似的疑问,因此针对这些问题写点东西,希望对一些微服务入门者有所帮助。

(1)如何将当前的产品拆解为微服务(组件),每个微服务应包括哪些元素?

要把单体式应用拆分成微服务组件,并没有一个具像的标准说这个组件应该包括哪些元素。而是需要从业务的角度去分析:某一些功能是否逻辑相对独立、可复用性高、使用频度高等等,根据这些因素判断是否该拆分出来作为一个微服务组件。

微服务设计强调服务的独立性:不同微服务使用不同的数据,与外部交互通过消息或API而不是耦合的依赖关系;此外,微服务组件的设计需要把握“微”的度,所以不宜在基础的功能上做过多的堆叠,否则每个微服务组件可能又变成了大的单体应用。

具体来说,微服务设计需要可从以下几个方面着手:

  • 实现前后端分离,可把代码分为前端、服务层、底层代码;
  • 根据业务逻辑及技术层面的系统架构综合考虑,抽取模块成服务;
  • 打造服务间的轻量通信基础组件及协议,例如REST或消息队列;
  • 此外设计时需要注意的很重要的一点是,微服务必须要支持的外部化配置,这种配包括任何占位符信息到数据库配置等等,在初始规划和构建应用原型时,这是必须要考虑的架构内容。

(2)如何搭建合理的微服务总线和通信机制?

这个问题提到的所谓的微服务总线实际上主要包括两方面的功能:服务发现和服务调用。

例如阿里开源的Dubbo框架就是一种微服务框架,它借助Zookeeper等多种注册中心实现对Provider服务的注册,并且提供服务发现功能。

Dubbo支持Hessian、WebService、Thrift等方式的RPC远程服务调用,此外当当扩展的dubbox还支持REST API的服务调用方式。

事实上更地道的微服务架构会采用基于异步通信的调用。在异步通信中,各服务间彼此依赖,但不会因相互等待结果而导致响应速度缓慢。因此,如果一项服务发生故障,其不会影响到其它服务,瓶颈与单点故障问题也将不复存在。


(3)如何保障负载均衡和微服务系统的整体可靠性?

参考Dubbo提供的ConfigServer的原理,就可知道如何保证微服务系统的负载均衡和整体的可靠性问题了。如果你的系统是Java应用,就可以使用现成的Dubbo,当然你也可以支持根据这个基本原理写自己的微服务支持框架。


Dubbo的配置中心和每个Server/Client之间会作一个实时的心跳检测,收集并更新每个Server提供的服务的信息,每个Client的信息。

每个Server启动时,主动与ConfigServer建立连接,并将自己的IP,提供的服务名称,端口等信息直接发送给ConfigServer,ConfigServer会更新服务列表。


Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息,后面就可以直接调用服务了。当有多个服务提供者的时候,Client根据一定的规则来进行负载均衡,如轮询,随机,按权重等。一旦Client使用的服务它对应的服务提供者有变化,ConfigServer就会把新的服务提供者列表推送给Client,Client重新建立连接。

(4)如何管理服务组件的版本,实现快速部署和无缝升级?

微服务架构下的应用由若干个微服务组件组成,与单体式应用相比其服务组件的版本管理及部署、升级都会变得复杂了,如果全靠手工去做,必然效率底下。


一套完善的开发管理规范,包括开发设计规范、分支管理规范、持续集成规范,再利用Docker容器的天然的特性:“版本控制、可移植性、隔离性”就可以实现组件的版本管理。实质上基于在支持DevOps完整流程的容器云平台,即可实现整个开发过程及交付中的持续集成、快速部署、灰度发布及无缝升级。

(5)如何搭建配套的服务控制台和管理系统?

在容器云平台上搭建你的开发、测试及运行环境可实现容器化的持续集成持续部署,即以容器的形式发布应用。平台可以提供容器服务的监控及管理的全套功能,无需自己搭建服务控制台和管理系统。

相关文章