基于 Kubernetes 的微服务项目设计与实现 第一章：微服务项目设计

随着互联网的发展，后端服务和容器编排技术的日益成熟，微服务成为了后端服务的首选，Kubernetes 也已经成为目前容器编排的事实标准, 微服务拥抱容器时代已经来临。

笔者结合自己的经验，写了这篇微服务+ Kubernetes 入门宝典，希望能够抛砖引玉，能让大家了解微服务和 Kubernetes 如何配合。本文主要描述微服务设计、项目实现、Kubernetes 部署、微服务的部署、高可用和监控这几个部分。

本文会从设计开始，设计一个简单的前后端分离的项目，并将它部署在 Kubernetes 集群上，期间我们将关注微服务和 Kubernetes 配合的各个方面，并且从系统的可用性，可靠性、强壮性、可扩展进行讨论，最终设计一个可以真正实用的系统。

整体上我们从 4 个章节描述这个目标，分别是：

第一章：微服务项目设计

第二章：微服务项目具体实现

第三章：Kubernetes 部署

第四章：微服务高可用部署及验证

微服务是一种设计思想，它并不局限于任何开发语言，在本例中我们选择 Java 的Spring Boot 框架来实现微服务。微服务之间的 RPC 方案也很多，我们这里选择 Restful 这种最常见的方案。为了项目的简洁，项目也没有涉及数据库和缓存，配置中心相关的内容。我们主要注重项目的设计思想实践和项目改进。

第一章：微服务项目的设计
 
1.1 微服务设计的思想
首先我们简单地回顾一下微服务，微服务的定义当来自 Martin Fowler https://martinfowler.com/articles/microservices.html 一文，借用大佬的一张图描述了微服务最本质的东西。

微服务把各个功能拆开了，每个模块的功能更加独立，也更加单一。每个模块都独立发展，可以说做到了功能的高内聚，低偶合。

再借一张，这样数据库也被彻底拆分开了。一个巨大复制的单体数据库也按照功能拆成了小的独立数据库。

微服务就是这么简单吗？当然不是，里面有很多细节需要考虑，纸上得来终觉浅,绝知此事要躬行。这次让我们开始从 0 开始真正的设计整套系统。

1.2 实践设计和改进
现在我们要设计一个最简单的微服务架构。为了更贴近真实的业务。我们假设这个系统是这样的。

整个系统的前端是一个有着前后端分离站点，用户访问了 www.demo.com 这个前端站点,通过前端页面发起请求，www.demo.com 服务器将请求发往 a.demo.com。然后 a.demo.com 再请求 b.demo.com，b.demo.com 再请求 c.demo.com。c.demo.com 将结果返回后，不断返回，最终显示在前端站点，完成微服务的全套调用流程。（一般业务系统在前端和微服务直接还存在一个网关部分，网关一般用于鉴权、请求分类、监控等功能，这里因为比较简单，所以省略了这个部分。）

最终我们将这套架构将部署在 Kubernetes 上，开始真正的服务用户。

 1.3 改进项目
从图一我们可以看到这是一个非常简单而单薄的架构，存在很多问题，我们需要不断地解决它们。下面我们开始改进项目。

首先，我们要解决节点的可靠性。在图一所有的节点都只有一个实例，任何节点的崩溃都将造成项目无法运行，在真正的项目中这是不可接受的。怎么解决呢？当然是多个实例。

1.3.1 加入多实例及注册中心

 我们将各个模块的实例数目增加，多个实例才能保证整个系统的可靠性。如果一个实例有问题，我们还是可以其他相同的实例进行服务。

但是多个实例又带来一个问题：各个组件之间如何定位呢？如果有 10 个 b.demo.com 实例，它的上下游又该如何找到它们呢？解决方案之一是注册中心。

注册中心解决的是应用之间的寻址问题。有了它，上下游之间的应用可以相互寻址，并且获知那些实例是可用的，应用挑选可用的实例进行工作。注册中心的方案很多，有 Eureka、Zookeeper、Console、Nacos 等等。关于讨论各种注册中心是 AP、CP 的区别和优劣的文章很多，这篇文章不是一篇微服务的开发教程，我们选择比较常见的 Eureka 为演示的注册中心。

注：在 Kubernetes 中部署微服务，对注册中心是没有任何限制的。所以不要被某些文章误导，按照这篇文章做，你完全可以做到代码零修改，直接在 Kubernetes 上运行。

1.3.2 监控系统 Metrics

在完成了注册中心的功能后，虽然整个系统可以运行了。我们会发现没有应用监控的情况下，我们对系统运转状态是完全摸黑的，这样相当于盲人骑马，非常危险。我们需要知道所有微服务运行的状态，必须将各个微服务的状态监控起来，只有这样才能做到运筹帷幄，决胜千里。

在这里，我们选择使用 Prometheus 和 Grafana 这套监控组合。Prometheus + Grafana 是一个比较常见的组合，基本是现在容器监控的标准配置。

在 Kubernetes 上，我们需要每个微服务的实例里开启监控数据到导出功能。同时利用 Prometheus 的自动发现功能，这样 Prometheus 可以将数据收集存储起来。

这里的数据包括每个应用的各项指标比如内存大小、200 错误数目、500 错误数目、JVM 里线程数量、GC 时间大小。配合 Granfana 的聚合显示能力，我们可以直观地对整个系统有完整把控。

在应用开发过程中，我们只需要在代码里加入一个类库就可以实现信息的导出，不需要专门写代码。

1.3.3 日志系统 logging

目前已经有了监控，日志还有存在的必要吗？当然 下面这个图就反应监控的3个维度。

这3个维度分别是Mertics Tracing 和logging

Metrics  主要就是指刚才说的监控，它主要反应的就是一个聚合的数据，比如今天200错误是多少，QPS是多少？它指的是一段时间内的数据聚合。

Logging 就是我们现在讨论的日志。的它描述一些离散的（不连续的）事件。比如各个系统里的错误，告警。所以我们需要将日志收集起来。

Tracing 则关注单次请求中信息。我们关注请求的质量和服务可行性，是我们优化系统，排查问题的工具。

说到了日志，在一个分布式系统，日志是非常重要的一环。因为微服务和容器的缘故，导致日志收集不是这么简单了。因为在kubernetes 里 容器的销毁和重启都是经常可能出现的，我们需要第一时间就把日志收集起来。

日志收集的方案有很多，有些方案是在本地启动一个收集进程，将落地的日志转发到kakfa组件再转发日志中心，也有的方案是直接写到kafka组件直接进入日志中心。两者各有优劣。

在这里，我们的方案选择了后者。我们简单地利用一个组件将日志直接打入kafka 组件。这种方案的好处是我们日志不再落地，日志IO被消除了，日志的存储也和容器做到了分离。我们再也不用担心日志IO对宿主机造成的系统压力了。

1.3.4      追踪系统 Tracing

刚才我们讨论了监控 (Metric)和日志(Logging)，还有一个维度就是追踪(Tracing).

随着微服务的实例越来越多，有一个很现实的问题出现了，当大规模分布式集群出现了，应用构建在不同的容器集群里、有可能布在了几千台容器里，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具。这该怎么解决呢？可以看看google的论文 google dapper

Google 的论文描述一种解决办法，我们一般称作APM(Application Performance Monitor). 它把一次调用加入一个独立无二的标记，并且在各个系统里透传标记，从而达到追踪整个消息处理过程的能力。市面上大多数实现都是基于这一思想,可选方案的有很多，如 cat pip, zipkin, skywalkin。它们有需要代码注入的，有无注入的。关于他们的优劣也有很多文章评述。在这里我们选用zipkin 。Zipkin 需要在项目中加入一个库，并不需要写代码，这对业务的入侵做到了很少，非常方便。

1.3.5 流量控制

你认为这一切就完了吗？当然不是，微服务里还有一项非常重要的功能：流量控制，我们还没有做。

当海量的请求来临的时候，我们可以用增加容器数量的办法来提高我们的服务能力，但是简单地添加实例是很危险的，因为整个系统的服务能力是被系统短板所限制的，简单地添加实例，并不是总能起到提高服务能力的作用。反而可能引起反作用，最终导致整个系统的崩溃。

我们对整个系统的负载容量是有一个设计的，当超出我们设计的能力时，我们需要对多余的请求说No。相应的方案分别是熔断、限流和降级。目前java领域的这方面的hystrix，sentinel 在这方面都做得很好。Sentinel 在阿里接受了考验，并且使用起来也很简单，所以我们选它。现在我们在整个系统里加上一个流量控中心。这样一个基本完整的 可靠的 高可靠的系统就基本完成了。

（在实际开发中，其实还有最关键的配置中心（apollo)，数据库（db）,缓存(redis) 等组件， 服务化网格， 我们可以把这些组件暂时放在kubernetes 之外，仍然是可以起到同样的效果）

好了设计部分，先到这里，开始实现。
-----------------------------------
基于 Kubernetes 的微服务项目设计与实现  第一章：微服务项目设计
https://blog.51cto.com/u_14035463/5584912