云原生之深入解析K8s中的微服务项目设计与实现

一、微服务项目的设计

① 微服务设计的思想

• 一个单片应用程序将被构建、测试并顺利地通过这些环境。事实证明，一旦投资于将生产路径自动化，那么部署更多的应用程序似乎就不再那么可怕了。请记住，CD的目标之一就是让部署变得无聊，所以无论是一个应用程序还是三个应用程序，只要它仍然无聊就没关系。
• 使用基础设施自动化的另一个领域是在生产环境中管理微服务，与我们上面的断言相反，只要部署是无聊的，那么单体服务和微服务之间就没有太大的区别，两者的运营环境可能截然不同。

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

• 这样数据库也被彻底拆分开了。一个巨大复制的单体数据库也按照功能拆成了小的独立数据库。微服务就是这么简单吗？当然不是，里面有很多细节需要考虑，纸上得来终觉浅，绝知此事要躬行。

② 实践设计和改进

• 现在要设计一个最简单的微服务架构，为了更贴近真实的业务，假设这个系统是这样的：

• 整个系统的前端是一个有着前后端分离站点，用户访问了 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 上，开始真正的服务用户。

③ 改进项目

• 从上图中可以看到这是一个非常简单而单薄的架构，存在很多问题，需要不断地解决它们。首先，要解决节点的可靠性，所有的节点都只有一个实例，任何节点的崩溃都将造成项目无法运行，在真正的项目中这是不可接受的，怎么解决呢？当然是多个实例。
• 加入多实例及注册中心：

• • 将各个模块的实例数目增加，多个实例才能保证整个系统的可靠性，如果一个实例有问题，还是可以其他相同的实例进行服务。但是多个实例又带来一个问题，各个组件之间如何定位呢？如果有 10 个 b.demo.com 实例，它的上下游又该如何找到它们呢？解决方案之一是注册中心。
• • 注册中心解决的是应用之间的寻址问题。有了它，上下游之间的应用可以相互寻址，并且获知那些实例是可用的，应用挑选可用的实例进行工作。注册中心的方案很多，有 Eureka，ZooKeeper，Consul，Nacos 等。
• • 在 Kubernetes 中部署微服务，对注册中心是没有任何限制的，完全可以做到代码零修改，直接在 Kubernetes 上运行。
• 监控系统 Metrics：
• • 在完成了注册中心的功能后，虽然整个系统可以运行了，可以发现没有应用监控的情况下，对系统运转状态是完全摸黑的，这样相当于盲人骑马，非常危险。我们需要知道所有微服务运行的状态，必须将各个微服务的状态监控起来，只有这样才能做到 运筹帷幄，决胜千里。

• • 在这里选择使用 Prometheus 和 Grafana 这套监控组合，Prometheus + Grafana 是一个比较常见的组合，基本是现在容器监控的标准配置。在 Kubernetes 上，我们需要每个微服务的实例里开启监控数据到导出功能。同时利用 Prometheus 的自动发现功能， 这样 Prometheus 可以将数据收集存储起来。这里的数据包括每个应用的各项指标比如内存大小，200 错误数目，500 错误数目，JVM 里线程数量，GC 时间大小。配合 Grafana 的聚合显示能力，我们可以直观地对整个系统有完整把控。在应用开发过程中，我们只需要在代码里加入一个类库就可以实现信息的导出，不需要专门写代码。
• 日志系统 Logging：
• • 目前已经有了监控，日志还有存在的必要吗？当然，下面这个图就反应监控的 3 个维度：

• • 这 3 个维度分别是 Mertics，Tracing 和 Logging：
• • • Metrics 主要就是指刚才说的监控，它主要反应的就是一个聚合的数据，比如今天 200 错误是多少，QPS 是多少，它指的是一段时间内的数据聚合；
• • • Logging 就是现在讨论的日志，它描述一些离散的（不连续的）事件，比如各个系统里的错误、告警，因此需要将日志收集起来；
• • • Tracing 则关注单次请求中信息，关注请求的质量和服务可行性，是优化系统，排查问题的工具。
• • 说到了日志，在一个分布式系统，日志是非常重要的一环。因为微服务和容器的缘故，导致日志收集不是这么简单了，因为在 Kubernetes 里容器的销毁和重启都是经常可能出现的，需要第一时间就把日志收集起来。
• • 日志收集的方案有很多，有些方案是在本地启动一个收集进程，将落地的日志转发到 Kakfa 组件再转发日志中心，也有的方案是直接写到 Kafka 组件直接进入日志中心，两者各有优劣。
• • 在这里，方案选择了后者，简单地利用一个组件将日志直接打入 Kafka 组件，这种方案的好处是我们日志不再落地，日志 IO 被消除了，日志的存储也和容器做到了分离，再也不用担心日志 IO 对宿主机造成的系统压力。

• 追踪系统 Tracing：
• • 刚才讨论了监控（Metric）和日志（Logging），还有一个维度就是追踪（Tracing），随着微服务的实例越来越多，有一个很现实的问题出现了，当大规模分布式集群出现了，应用构建在不同的容器集群里、有可能布在了几千台容器里，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，这该怎么解决呢？

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

• 流量控制：
• • 到这里，这一切就完了吗？当然不是，微服务里还有一项非常重要的功能：流量控制还没有做。当海量的请求来临的时候，可以用增加容器数量的办法来提高服务能力，但是简单地添加实例是很危险的，因为整个系统的服务能力是被系统短板所限制的，简单地添加实例，并不是总能起到提高服务能力的作用。反而可能引起反作用，最终导致整个系统的崩溃。
• • 对整个系统的负载容量是有一个设计的，当超出设计的能力时，需要对多余的请求说 No。相应的方案分别是熔断、限流和降级。目前 Java 领域的这方面的 Hystrix，Sentinel 在这方面都做得很好。Sentinel 在阿里接受了考验，并且使用起来也很简单，所以选它。现在在整个系统里加上一个流量控中心，这样一个基本完整高可靠的系统就基本完成。

• 在实际开发中，其实还有最关键的配置中心（Apollo)，数据库（DB），缓存（Redis）等组件， 服务化网格， 可以把这些组件暂时放在 Kubernetes 之外，仍然是可以起到同样的效果。

二、微服务项目的具体实现

① 前端站点

• 前端站点的逻辑很简单，就是显示一个页面，页面中有一个按键，当点击按键的时候，前端页面发起 ajax 请求，访问前端站点本身的一个接口，这个接口被 Nginx 代理，转发到 a.demo.com 微服务上，a. demo.com 微服务再将请求转发到 b. demo.com，b. demo.com 再将请求转发到 c. demo.com，最终将结果返回给前端，前端站点再将结果显示在页面上。通过结果显示，就能知道这次请求通过了那些服务器，每台服务器的服务运行时间大概是多少。
• 前端站点代码大体如下：

• 然后看 a、b、 c 应用部分的 Java 代码，这就是个普通的多模块 Maven 项目：

• 项目很简单，分成了 3 个部分，一个是注册中心，也就是利用 Eureka 实现注册中心服务，另一个则是基础库项目，大部分功能都在这里实现，最后则是各个微服务项目，微服务项目只需要简单调用基础库就能完成。

② 注册中心

• 注册中心的代码非常简单，只需要加一个简单的声明：

• 这是注册中心的配置文件，在 Kubernetes 集群里运行时，可以运行 3 个节点组成高可用的注册中心集群，这时这个配置项需要相应的修改：

③ 基础库

• 在基础库项目里，将很多的依赖都放在里面，这样应用项目只需要简单依赖基础库就可以，能够做到统一修改，同时也可以看到大部分依赖库只需要加入就可以，并不需编写代码就可以工作，这让开发工作变得轻松。

• 对于微服务的返回结果，做一些美化格式，这样可以在检查结果时，比较容易：

• 简单的定义了一些返回的结构，可以通过这些结构，微服务可以把处理时的时间戳，线程号，实例 IP 这些信息返回出来：

• 基础模块的日志实现，从 GitHub 找的例子简单地进行了修改（这里只是简单实现，不要用于生产），这时，利用 logback.xml 的配置，可以把日志写入本地磁盘还是直接写入 Kafka：

• a.demo.com，b.demo.com，c.demo.com 应用实现：

• 实现很简单，只是简单地调用基础库就可以了。注意每个应用需要实现一个探活接口 /hs，这样 Kubernetes 系统可以通过这个接口来探活，获知这个应用是不是准备好了，能不能接入流量，否则这个应用可能还在启动过程中，但是流量已经接入了，那么肯定会出问题。

• 在每个应用的配置里，都预置了各个配置的项目，在本地运行的时候，可以填注入本地的配置，在 Kubernetes 里以容器形式进行运行，可以利用 yaml 来动态地修改它们，做到 2 种情况下完全兼容。

三、Kubernetes 的部署

• 在完成应用的编写后，需要安装 Kubernetes 系统，如果已经有 Kubernetes 集群的，就可以直接跳过这个部分。除了 Kubernetes 集群以外，还需要 Prometheus and Grafana 这样的监控组件，因此这里推荐一个牛逼的安装工具，和所有现有的 Kubernetes 安装工具比，它是最好的，没有之一。
• 它的名字是 K8seasy，它的优点在于：
• • 可以一键安装整体 Kubernetes 系统，无需了解任何背景知识；
• • 所有的镜像都已经内置，不会因为下载镜像失败而导致失败；
• • 安装支持各种不同版本 Kubernetes 版本；
• • 安装的服务是二进制版本的，非容器版本，稳定高效；
• • 支持安装 3 节点 高可用的生产环境集群。

① 安装过程

• 下载 K8seasy：K8seasy 的官方主页；
• K8seasy 的安装下载页：

• 将 3 个安装文件都下载下来，其中 pack.2020.10.02.bin 和 installer 都是安装文件， kubernetes-server-linux-amd64.tar.gz 是 Kubernetes 的官方软件包，可以自己选择一个最新的版本。如果要选择一个其他版本的 Kubernetes：

• 安装的过程很简单，2 条命令即可，这里假设需要安装 Kubernetes 的网络为 192.168.2.0，master 主机为 192.168.2.50。

② 创建密钥

sudo ./installer --genkey -hostlist=192.168.2.1

③ 创建集群

sudo ./installer   -kubernetestarfile kubernetes-server-linux-amd64v1.18.2.tar.gz -masterip 192.168.2.50

• 稍等一会儿就能看到类似如下输出：

• 就这么简单，一个 Kubernetes 已经装好了，此时相关的所有监控已经被完全安装好了。

④ 各项监控

• 以 Master 节点为 192.168.2.50 为例，http://192.168.2.50:10000 可以直接打开 Dashboard，对整个集群有一个全面了解：

• 打开 http://192.168.2.50:8080，可以直接访问 Alertmanager：

• 打开 http://192.168.2.50:8081，可以直接使用 Grafana（用户 admin，密码 admin）：

• 打开 http://192.168.2.50:8082，可以访问 Prometheus：

⑤ 多套环境监控

• 为了支持多集群管理，再推荐一个工具，刚才说到直接使用 http://192.168.2.50:1000 这个页面可以直接管理整个集群，但是在公司里如果有多个集群，该如何管理呢？别担心，K8seasy 已经有对应的解决方案。

• 仔细看刚才的安装好的日志，里面提示专门生产了一个 lens.kubeconfig 的配置文件，并且有一个域名和 IP 的对应表。这时候，只需要首先在本地 Host 文件里加入这个对应：

• 然后去 https://Kuberneteslens.dev/：

• 下载一个 Lens 的安装包，安装 Lens 以后，只需要将 lens.kubeconfig 导入到 Lens 里：

• 导入完成后，就可以远程管理这个集群了，这样有多个集群，也可以只用一套 Lens 进行管理，Lens 的界面优美，使用方便。

• 好了，Kubernetes 的安装完成，当然了 K8seasy 的功能是非常强大的，可以用 sudo ./installer -h 查看帮助， 也可以使用 sudo ./installer -demo 查看各种场景的安装帮助：

四、微服务高可用部署及验证

① 服务部署上去

• 依次运行每条部署 Yaml 的命令即可，不需要做其他的操作。
• 注意，镜像在 Docker-Hub，可能需要一定时间才能下载。
• 运行后在 Dashboard 查看，你可以看到类似的信息，所有的服务都已经成功运行。

② 查看 Dashboard

• 此时修改本地的 Hosts：

• 这样的话，因为 Kubernetes 是支持 nginx-ingress 的，因此可以直接访问 Master 的物理 IP 来访问这些服务，不需要做任何转换。
• 首先可以打开 Dashboard 从中查到 Eureka，服务器的具体 IP，然后访问 Eurka 服务。

③ 查看注册中心

• 在页面中可以发现，在 Kubernetes 集群里，启动 3 个 Eureka 服务，它们相互注册，组成了一个高可用集群：

• 其次，在 Grafana 中导入 JVM 的监控项目：

• 这样 Grafana 可以把各个 Java 服务的具体状态做一个收集，完成我们需要的监控。

④ 前端验证

• 此时，打开 http://www.demo.com 的网页，可以点击页面上的 get 请求按键，模拟发出请求，随后就会发现页面里显示出的信息在不断变化：

• 在页面显示的内容里，可以清楚地发现，消息在不同实例里处理，如果有一个实例出现了故障是不会影响我们现在的业务的：

⑤ 模拟验证

• 使用一个简单的脚本，模拟每 3 秒从前端访问一次后端：

⑥ 调用关系验证

• 首先打开 Zipkin：zipkin.demo.com：

• 点击具体的请求，可以查看到每次请求在内部的细节：

⑦ 限流熔断验证

• 打开 Sentinel 站点，这个站点可以监控，也可以对微服务进行限流，限速，熔断等操作（密码口令都是 Sentinel）：

• 进入控制台后，可以发现所有的服务已经自动被发现，并存在于左边的菜单：

• 分别点开 a、b、c，3 个服务，可以看到规律的周期访问，和脚本的测试速度是一致的：

⑧ 应用状态验证

• 打开 Grafana 的监控页，可以查看所有应用的状态，包括 heap 大小，启动时间，错误数目等：

• 通过这张图可以了解每个应用本身的状态，使用了多少内存，响应的代码是多少，JVM 使用情况。相信此时已经对各个组件的情况，监控都有了一个全面了解，一个基于 Kubernetes 的微服务架构已经开始工作。