【你问我答】是 BoCloud 博云最新上线的互动类栏目，每周我们将收集和整理有关容器、微服务、DevOps、多云管理等方面的 企业 IT 建设问题，由博云产品团队进行详细解答。如果你有任何感兴趣的相关问题，欢迎留言提问。
以下是本周 “ 微服务 ” 相关问题精选：
网友1：微服务治理应该如何去做？
微服务化应该是从企业的单个系统考虑，还是从整体IT架构去考虑？微服务治理应该如何去做？
博云产品团队：微服务的治理分很多方面，简单的来谈至少三个层面：
1. 微服务底层管理，微服务之所以需要治理，是因为其逻辑复杂，运维困难，所以需要提供注册中心，配置中心，网关，监控等多种组件做为帮助，所以这个层面是对这些组件的治理。
- 微服务外层治理，主要关注于用户的使用，这就涉及到 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 建设的相关问题。