你问我答:微服务治理应该如何去做?

【你问我答】是 BoCloud 博云最新上线的互动类栏目,每周我们将收集和整理有关容器、微服务、DevOps、多云管理等方面的 企业 IT 建设问题,由博云产品团队进行详细解答。如果你有任何感兴趣的相关问题,欢迎留言提问。

以下是本周 “ 微服务 ” 相关问题精选:

 

网友1:微服务治理应该如何去做?

微服务化应该是从企业的单个系统考虑,还是从整体IT架构去考虑?微服务治理应该如何去做?

 

博云产品团队:微服务的治理分很多方面,简单的来谈至少三个层面:

 

1. 微服务底层管理,微服务之所以需要治理,是因为其逻辑复杂,运维困难,所以需要提供注册中心,配置中心,网关,监控等多种组件做为帮助,所以这个层面是对这些组件的治理。

2. 微服务外层治理,主要关注于用户的使用,这就涉及到 DevOps ,需要对服务的全生命周期做治理,从想法到实现,再到更新升级。当然这里很重要的一块就是用户权限等问题,部门角色也不可忽略的。

3.从微服务的业务层治理,算是微服务的上层治理,这一层主要关注于服务的业务实现,跟踪业务的调用链,发现调用过程中的逻辑问题,效率问题,冗余问题等等。

网友2:微服务框架,容器云,ServiceMesh、传统API Gateway产品都提供注册发现,它们各适合什么场景?如何选型?

服务化架构中,服务注册和发现是重要的组件,微服务框架中有注册发现,比如Eureka, consul等,容器云也提供服务注册和发现,ServiceMesh、传统API Gateway产品也有注册发现,它们各适合什么场景?如何选型?

博云产品团队:服务注册是指服务提供者将自身信息上报至平台,服务发现是服务消费者到平台查找自己需要的服务。

1. 微服务框架中,服务是由自身启动,并将信息注册到注册中心,如果不加服务注册信息,那么平台将不知道也不能控制该服务。而且微服务框架下,平台是被动的,不能实现服务资源的主动调度。

2. 容器云,现在一般都是使用 kubernetes 做为容器的调度,服务的启动都是以 pod 的形式,以 service 向外提供服务。从平台的角度来说无需服务注册与发现。kubernetes 具有强大的服务资源调度能力,所以服务的启停平台占据主动权。与微服务框架相比,服务原生的负载均衡、访问控制将被废除,而由 kubernetes 提供,但功能较弱。

3. ServiceMesh 可以说是微服务框架的一个升级版,让服务只专注于服务自身的功能,将其内部的服务注册、负载均衡、网络等功能,全部拆出来,以依赖服务的形式存在。其实这里的服务注册与发现,与微服务框架的理念没有太大差别。

4.传统 API Gateway,在微服务框架中也是经常使用的组件,主要是用来控制服务访问的,不管是内部服务间,还是向外部提供业务,主要是用来做安全控制的,当然其他功能还有很多。

网友3:我们处在微服务+容器的转型探索时期,微服务框架:Dubbo、Spring Cloud、Service Mesh等发展趋势探讨?

博云产品团队:纯粹微服务开发,不考虑服务线上运维的要求,spring cloud 是首选,组件多,生态好。

基于通信延迟要求较小的情况下,采用 rpc 协议比 http 协议通信要好一些,dubbo 占优势 service mesh 是解决服务通信的基础设施,本身与微服务无关。

如果考虑容器化的方式部署,spring boot+kubernetes+spring cloud部分组件会更好一些,可以有效的减少组件依赖以及链路调用关系。

网友4:微服务拆分的原则?

按分享的经验来看,是需要将无关的功能都进行拆分,我理解就是原子化拆分。但现实业务场景中对于传统的应用系统,已经存在了大量的业务逻辑处理。这种迁移是一个比较长期且痛苦的事情,如何解决?

博云产品团队:服务拆分大的前提可以参考 DDD 领域驱动设计。进一步讲,业务需要考虑三方面问题:1.服务边界切分;2.服务依赖梳理;3.服务交互规范标准。

 

  • 服务边界切分需要依赖“低耦合,高内聚”的原则,明确业务单元的边界,尽可能减少同一个业务的不同服务单元的调用依赖。

  • 服务依赖,需要明确一个业务构成过程中的服务依赖关系,避免出现回环依赖,双向依赖的场景。最好的方式是实现链式依赖调用。

  • 服务交互规范,从协议以及数据传输规范层面说明服务与服务之间的交互方式,包括采用的通信协议,数据传递格式等;

服务迁移的过程中,首先要考虑接口变化情况,对于前后端分离的架构,可以采用restful 的方式进行,尽可能避免接口的频繁变更。同时复用原有的业务代码实现。线上迁移过程中,可以利用负载路由的控制实现逐步发布。

网友5:微服务架构下底层数据存储的实现方式?

从分享的材料来看,使用了分布式的多个数据库存储,从而达到高并发支持。在这种架构下,数据一致性的要求就很高,能否详细说明一下底层数据的同步方式?

博云产品团队:无论是否采用微服务架构,针对高并发的支持的情况,数据存储可以分为两个阶段:第一持久化存储;第二缓存。

针对持久化存储,首先微服务架构的各个服务是分库存储,针对不同的数据类型,可以采用不同的数据持久化引擎。例如关系型数据可以采用 mysql 做数据持久化引擎,时序数据可以采用influxdb,以及其他擅长存储不同数据类型的持久化引擎。但是需要注意集群化部署时的数据同步,数据备份以及故障切换等问题。针对缓存的,是对数据库的补充,能够有效的避免平凡操作数据库,导致请求延迟增大的效果。

针对数据同步以来 CAP 原理,首先需要考虑业务需求,需要满足强一致性,还是最终一致性来保证。根据不同的特性,可以选择其他的存储引擎,例如 etcd,zookeeper,consul 等。

网友6:微服务的高可用主要用什么方法保证高可用呢?硬负载均衡设备,还是软负载方式保证?

博云产品团队:高可用有两种不同的方式:主从,双活。与具体采用的服务架构关系相对没有那么紧密。软负载,或者硬负载在项目的实施过程中都会遇到。从适用场景而言,软负载更多适用在内网环境,内部服务与服务的交互接口处;硬负载更多呈现在整个应用的入口处,除了负载以外同时包含部分网关的功能。

 

 

下周预告:

关于 “ DevOps ” ,任何你感兴趣或者想了解,欢迎留言,下周我们将为大家解答有关 DevOps 建设的相关问题。

posted @ 2020-08-03 11:09  云原生社区干货  阅读(590)  评论(0编辑  收藏  举报