微服务相关

注：转自 https://www.oschina.net/question/3820517_2286266

1.微服务架构思想

解耦业务，提高灵活性，允许在服务频繁发版的同时保持系统其它部分的可用性和稳定性，解耦编程语言，针对不同业务采取不同语言开发；解耦开发团队，不同团队各自负责一个微服务，互不影响，加速交付

2.微服务拆分粒度

拆分依据：业务拆分很重要，基于业务，适合的是最好的，

原则：拆分完成后能够快速响应需求变化，满足并发，能够快速迭代，支持复用

前后端分离 是必要的，不是一个端（网页，客户端，手机）

拆分方法： AKF 扩展立方体 它讲的是通过三个维度上的扩展，可以快速提高产品的扩展能力，适应不同场景下产品的快速增长。同时，服务就尽量设计成无状态的，方便横向扩展

3.微服务不同环节，不同功能模块如何协调

在整个微服务架构过程中，包含了多个环节、多个功能模块的参与，拆分业务、网关、部署、数据库、文档、上线……这些环节和功能模块具体是如何协调起来的？

1. 开发人员完成需求的功能后，提交代码到代码仓库（SVN 或者 Git），Jenkins 从代码仓库拉取项目分支代码。
2. 执行构建，一般使用 Maven 进行项目的构建，当然也可以采用其他的构建工具。Maven 从 Nexux 私服摘取需要的 jar 包信息，完成编译。
3. 编译完成后会自动触发单元测试，测试所有应用的单元测试代码。
4. 单元测试通过后，触发 sonarcube 客户端执行静态代码检查，并且生成检查报告。
5. 编译和构建完成后，需要生成 Docker 镜像。
6. 将镜像发送到测试环境进行发布，触发自动化测试流程。
7. 如果测试不通过，则触发回归流程，测试通过，将已经打包好的镜像推送到预发布环境。
8. 预发布环境测试没有问题后，就可以进行灰度发布，将系统发布到线上环境

4.微服务架构有一些反模式，在实际操作中，比较普遍的反模式有哪些呢？如何避免？

数据驱动的反模式

单体应用迁移到微服务架构有两个主要目标：

• 第一个目标是单体应用程序的功能分割成小的、单一用途的服务。
• 第二个目标是单体应用的数据迁移到每个服务自己独占的小数据库。

第二种很容易导致的一个问题就是数据库的拆分不明确，可能粒度过粗，也可能粒度过细；还有一个问题就是数据的迁移。所以在微服务拆分的时候，功能分割优先，数据迁移最后。

超时反模式

分布式应用的挑战之一就是如何管理远程服务的可用性和它们的响应。一般情况下服务消费者可以选择无限期等待或者设置超时时间，使用超时时间看起来是个好办法，但是它会导致超时反模式。

所以一般使用断路器模式来处理，这种设计模式就像家里电器的保险丝一样，当负载过大，或者电路发生故障或异常时，电流会不断升高，为防止升高的电流损坏电路中的某些重要器件或贵重器件，烧毁电路甚至造成火灾，保险丝会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。

断路器模式相比设置超时的优点是，使用者可以立即知道服务已变得不响应，而不必等待超时，使用者将在毫秒内服务不响应。

另外断路器可以通过几种方式进行监控，最简单的方法是对远程服务进行简单的心跳检查，这种方式只是告诉断路器服务是活的，但是要想获取服务存活的详细信息，就需要定期（比如 10 秒）获取一次服务的详细信息。还有一种方式是实时用户监控，这种方式可以动态调整，一旦达到阈值，断路器可以进入半开放状态，可以设置一定数量的请求时通过。

共享反模式

微服务是一种无共享的架构，但因为总有一些代码会在微服务之间共享，这种共享不仅破坏了每个服务的限界上下文 (Bounded Context)，而且还引入了几个问题，包括整体可靠性、更改控制、可测试性和部署能力。

代码的共享通常会带来很多问题，微服务架构的主要目标就是共享要尽可能地少，这有助于维护服务的限界上下文，使我们能够快速的测试和布署。服务之间依赖越强，服务隔离也就越困难，因此也就越难单独进行测试和布署。

解决方法是在需要共享的部分通过复制和服务合并的方式来处理。

报表处理中的反模式

其实微服务中有 4 种方式处理报表类业务，分别是：

• database pull model，从数据库中直接拉取
• HTTP pull model，HTTP 拉取
• batch pull model，批量拉取
• event-based push model，基于事件推送

前三种是从服务的数据库中拉取数据，第 4 种方式是通过事件的方式生成数据。

database pull model 就是从数据库中直接拉取，虽然这看似乎是个好主意，但它导致了服务之间的明显依赖关系，会带来数据库的非独立性。

HTTP pull model 是 HTTP 拉取模型，使用此模型不需要直接访问每个服务的数据库，使用者只需要对每个服务发出一个 REST HTTP 调用就可以访问其数据。但是这种方式又太慢，无法满足复杂以及数据量较大数据获取需求。

batch pull model 是批量拉取模式，这种方式是独立出一个报表数据库或者数据仓库，通过批处理作业将不同服务数据库的数据拉取这个新独立的数据库中，这种模型的问题在于依然是强依赖数据库，如果拉取服务的数据库进行了更新，那么这个批量数据拉取过程也必将修改。

event-based push model 是避免报表处理反模式的一种有可取模式。当各微服务所拥有的数据库发生变更时，便会产生一个事件，此事件会使得生成报表的服务去处理此事件，到发生数据库变更的微服务中获取所变更的数据，并写入其所拥有的数据库或数据仓储中。

此设计方案不仅维持了各微服务的界限上下文，更使得生成报表的服务所拥有的数据库或数据仓储，获得实时的各微服务所拥有的数据库中的数据。

5.沙粒陷阱

架构师和开发人员在采用微服务架构的时候最大的挑战之一就是服务粒度的问题。服务粒度至关重要，它会影响应用的性能、健壮性、可靠性、可测性、设置发布模型。

这种陷阱的主要原因之一是开发人员常常将服务与类混淆，往往一个类就是一个服务，在这种情况下会很容易遇到沙粒陷阱。

服务应该被看成是一个服务组件，服务组件应该有一个清晰简明的角色和责任定义，并有一组明确的操作。由开发人员决定服务组件应该如何实现以及服务需要多少个实现类。

要避免沙粒陷阱，主要就是看如何衡量微服务的粒度，像前边说的，可以从这几个角度来考虑：

• 分析服务的范围和功能
• 分析数据库事务
• 分析服务调用顺序

所以建议服务粒度拆分的时候，将团队中架构以及相关人员聚集到一起，来平衡各个服务拆分的粒度，以最终确认服务拆分的合理性。

6.微服务数据库问题

在微服务架构中，数据库可以是分布式的，每个服务带一个库，也可以是集中式地只有一个，现在通用的模式是哪种呢？具体是怎么样的？分别有什么优劣？与 Database Mesh 又有什么关系？

就我们的业务而言，鼓励在不拆分能够满足业务的情况下，就不进行拆分，当无法支撑业务并发时，才进行拆分。

我们直接看微服务的设计模式，从中可以得到关于数据库设计的一些相关信息。

微服务的设计模式主要有以下几种：

链式设计模式

链式设计模式是常见的一种设计模式，用于微服务之间的调用，应用请求通过网关到达第一个微服务，微服务经过基础业务处理，发现不能满足要求，则继续调用第二个服务，然后将多个服务的结果统一返回到请求中。这是一服一库的设计。

聚合器设计模式

聚合器设计模式是将请求统一由网关路由到聚合器，聚合器向下路由到指定的微服务中获取结果，并且完成聚合。首页展现、分类搜索和个人中心等通常都使用这种设计。这是一服一库的设计。

数据共享模式

数据共享模式也是微服务设计模式的一种。应用通过网关调用多个微服务，微服务之间的数据共享通过同一个数据库，这样能够有效地减少请求次数，并且对于某些数据量小的情况非常适合。很显然，这是多服一库的模式。

异步消息设计模式

异步消息设计模式乍看起来跟聚合器的设计方式很像，唯一的区别就是网关和微服务之间的通信是通过消息队列而不是通过聚合器的方式来进行的，采用的是异步交互的方式。这也是一服一库的模式。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效地梳理。其实在这个概念没提出之前，一直都存在数据治理，而 Database Mesh 目前来看，更多的还是在概念阶段。

7.微服务与容器，云的关系

讲微服务离不开容器（容器技术和容器编排）与云（函数计算、无服务架构、云原生等），从微服务到容器，又再联系到云，似乎它们就是一体的，那具体它们是什么关系，怎么联系起来的？

容器技术可以说是微服务和云的最佳结合。国外的 Google，国内的京东都已经高调地宣称其业务在容器内完成。而提到这个，就一定要说一下 Kubernetes。以前的虚拟化技术更多是使用 OpenStack，而目前更多使用基于 Kubernetes 的容器取代 OpenStack。

我们知道，云从概念上来说可以分为 IaaS、PaaS 和 SaaS，有关云计算“水煤电”的比喻似乎预示了 IaaS 的未来。换句话说，电厂赚钱吗？答案是肯定的，但前提是垄断。

关于 IaaS、PaaS 和 SaaS 概念，可以查看 https://blog.****.net/qq_34386891/article/details/79621599

另一方面，对于很多中小企业来说，相比于 IaaS 的部署复杂性和不可避免的运维成本，基于 IaaS 的 PaaS 和 SaaS 似乎更符合自己的胃口。而从历年的调研数据来看，IaaS 的同比增长呈现出不断下滑的趋势，而 SaaS 和 PaaS 的增长态势要更加良性。

在这场关乎 IaaS 市场地位的争夺中，两个比较出众的技术就是微服务架构和 Docker。而以 Docker 为技术又兼顾微服务优势的容器云，开始被称之为新一代云计算模式。

IaaS 的建立可以看作是从 0 到 1，而容器的出现则是从 1 到 10 的结果。

举一个电商的例子来说，电商业务中购物车、订单、用户信息、配送、库存都能够提取成独立服务，研发团队可高频度独立更新各个微服务，从而能够控制变更范围，极大加速产品的迭代。

按照这个思路，IaaS 提升了资源的交付形式，容器则改变了产品的迭代方式，提高了产品迭代的速度，在这个唯快不破的时代，这一特性的颠覆意义不言而喻。

在 2014 年之前，我们公司的应用程序都部署在物理机器上，这有许多问题：在物理机器时代，为了给即将上线的应用程序分配物理机器，我们平均需要等上一周的时间；由于缺乏隔离机制，应用程序会彼此影响，导致了许多潜在风险；那时候，每个物理机器上的 Tomcat 实例的平均数量至多 9 个；物理机器的资源严重浪费，而且调度缺乏灵活性；由于物理机器的故障，应用程序迁移的时间要花数小时；无法实现自动扩展。

为了提高应用程序部署的效率，我们开发了编译-包装、自动化部署、日志收集、资源监控及其他一些系统。

2014 年，我们开始关注 Docker，最开始的时候是将容器当成虚拟机来使用。所有应用程序在容器里面运行，而不是在物理机器里面运行。开发人员在生产环境请求计算资源所花的时间由原来的一周缩短到了短短几分钟。

之后随着 Kubernetes 的开源，我们在其基础之上进行定制化开发，提供了一站式服务，比如日志、监控、故障排除、终端和编排。

8.Service Mesh

Service Mesh 是一个专用的软件基础设施层，用于控制和监控微服务应用中服务之间的内部通信，让服务相互间通信变得快速、安全和可靠。它通常表现为“数据平面”和“控制平面”。

作为 Sidecar 运行，Service Mesh 对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 Serivce Mesh 中实现，这样也就无需关注服务之间的那些原来是通过应用程序或者其它框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh 的来龙去脉：

1. 从最原始的主机之间直接使用网线相连
2. 网络层的出现
3. 集成到应用程序内部的控制流
4. 分解到应用程序外部的控制流
5. 应用程序的中集成服务发现和断路器
6. 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
7. 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 像上边的专用于服务发现和断路器的软件等往往是各公司基于自己的基础设施开发的，没有通用性，这就促使了最后作为微服务的通用中间层的 Service Mesh 的出现

具体到我们自己的实践中，经历了这么一个过程。在最开始，我们做服务化的时候，那个时候还没有微服务的概念，更多的谈及的是 SOA，还主要停留在 Web Service 和 ESB 总线等技术和规范上。

而在开源的领域，可选的方案并不多，所以服务间的通信什么的我们是直接选择的阿里开源的 Dubbo。Dubbo 提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，使得应用可通过高性能 RPC 实现服务的输出和输入功能，和 Spring 框架可以无缝集成。

Dubbo 包含远程通讯、集群容错和自动发现三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何 API 侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的 IP 地址，并且能够平滑添加或删除服务提供者。

之后我们使用的是微服务套件 Spring cloud 来进行整体的微服务管理。Spring Cloud 作为一个微服务的开发框架，包括了很多组件，包括：Spring Cloud Netflix（Eureka、Hystrix、Zuul、Archaius）、Spring Cloud Config、Spring Cloud Cluster、Spring Cloud Consul、Spring Cloud Sleuth 等。