预警诊断的微服务架构-学习笔记

还没有接触过微服务，学习它应该是一个漫长的过程。之前学习东西的时候都是采用手写笔记，第一次开博客，用来做为自己的电子笔记。因此整篇文章记录的是我自己的学习之路，不会有全面的介绍和学习，只是记录我个人的一些笔记碎片，本笔记随技术迭代随时更新，作者会长期维护。

注：图片均来自网络，如有侵权请及时告知。

2024.11.19更新小记：添加dokcer简介，后续准备整理成合适的项目技术架构。

2023.10.17更新小记：随着作者业务发展，目前成功将微服务应用于日志系统的预警及诊断服务。

2020.08.21更新小记：添加流程图，方便记忆。

2016.05.30更新小记：删除原有SOA相关内容，更新成主流微服务架构。

Docker 是一个开源的应用容器引擎，诞生于 2013 年初，最初是 ‌dotCloud 公司内部的一个业余项目。Docker 基于 ‌LXC（‌Linux 容器技术）进行封装，让用户不需要关心容器的管理，操作更为简便。Docker 项目后来加入了 ‌Linux 基金会，并遵从 Apache 2.0 协议，项目代码在 GitHub 上进行维护。由于 Docker 的广泛应用，dotCloud 公司后来改名为 Docker Inc。

Docker 通过容器技术，让开发者可以将应用及其依赖打包进一个轻量级的、可移植的容器中，然后发布到任何流行的 Linux 机器上。Docker 容器完全使用沙箱机制，相互隔离，性能开销极低。与传统的虚拟机相比，Docker 容器启动更快，资源利用率更高。一台主机上可以同时运行数千个 Docker 容器，而且容器除了运行其中的应用外，基本不消耗额外的系统资源。

图示：微服务架构图

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API)，并提供规范的API接口。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

容错：当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库)的服务单元，Spring Cloud就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud做为大管家就需要提供各种方案来维护整个生态。Spring Cloud就是一套分布式服务治理的框架，既然它是一套服务治理的框架，那么它本身不会提供具体功能性的操作，更专注于服务之间的通讯、熔断、监控等。

1)服务的注册与发现

图示：服务注册发现图

由两个组件组成：Eureka服务端和Eureka客户端。Eureka服务端用作服务注册中心。支持集群部署。Eureka客户端是一个java客户端，用来处理服务注册与发现。在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

2)配置管理

图示：配置管理图

Spring Cloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。所有的常用配置直接在配置中心完成，修改变更都不需要影响代码。

3)服务负载均衡

图示：客户端负载均衡图

负载均衡是对系统的高可用、网络压力的缓解和处理内容扩容的重要手段之一。负载均衡可以分为客户端负载均衡和服务端负载均衡。负载均衡按设备来分为硬件负载均衡和软件负载均衡，都属于服务端负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备。软件负载均衡通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求的转发工作，例如Nginx等。硬件负载均衡和软件负载均衡都会维护一个可用的服务清单，然后通过心跳检测来剔除故障节点以保证服务清单中的节点都正常可用。当客户端发出请求时，负载均衡器会按照某种算法(线性轮询、按权重负载、按流量负载等)从服务清单中取出一台服务器的地址，然后将请求转发到该服务器上。客户端负载均衡需要客户端自己维护自己要访问的服务实例清单， 这些服务清单来源于注册中心(在使用Eureka进行服务治理时)。

4)熔断机制

图示：熔断机制图

为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

5)服务网关

图示：服务网关图

在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

6)链路追踪

图示：链路追踪图

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。通过链路追踪可以很清楚的看出一个请求都经过了那些服务，可以很方便的理清服务间的调用关系等。性能分析，可以很方便的看出每个采样请求的耗时，分析哪些服务调用比较耗时，当服务调用的耗时随着请求量的增大而增大时， 可以对服务的扩容提供一定的提醒。数据分析，优化链路，对于频繁调用一个服务，或并行调用等，可以针对业务做一些优化措施。

7)虚拟容器

软件环境配置是开发最大的麻烦事之一，用户计算机的环境不相同，用户必须保证操作系统的设置及各种库和组件的正确安装，软件才能运行。随着业务的不断的发展，与之对应的就是微服务越来越多，每个微服务都要提供单独的环境支持，每个微服务也需要更好的管理，所以我们就引入了Docker和Kubernetes。

图示：虚拟化容器图

虚拟机（virtual machine)就是带环境安装的一种解决方案。它可以在一种操作系统里面运行另一种操作系统，比如在 Windows 系统里面运行 Linux 系统。应用程序对此毫无感知，因为虚拟机看上去跟真实系统一模一样，而对于底层系统来说，虚拟机就是一个普通文件，不需要了就删掉，对其他部分毫无影响。

虽然用户可以通过虚拟机还原软件的原始环境。但是，这个方案有几个缺点。

资源占用多：虚拟机会独占一部分内存和硬盘空间。它运行的时候，其他程序就不能使用这些资源了。哪怕虚拟机里面的应用程序，真正使用的内存只有 1MB，虚拟机依然需要几百 MB 的内存才能运行。

冗余步骤多：虚拟机是完整的操作系统，一些系统级别的操作步骤，往往无法跳过，比如用户登录。

启动慢：启动操作系统需要多久，启动虚拟机就需要多久。可能要等几分钟，应用程序才能真正运行。

Linux 发展出了另一种虚拟化技术：Linux 容器（Linux Containers，缩写为 LXC)。Linux 容器不是模拟一个完整的操作系统，而是对进程进行隔离。或者说，在正常进程的外面套了一个保护层。对于容器里面的进程来说，它接触到的各种资源都是虚拟的，从而实现与底层系统的隔离。由于容器是进程级别的，相比虚拟机有很多优势：

启动快：容器里面的应用，直接就是底层系统的一个进程，而不是虚拟机内部的进程。所以，启动容器相当于启动本机的一个进程，而不是启动一个操作系统，速度就快很多。

资源占用少：容器只占用需要的资源，不占用那些没有用到的资源；虚拟机由于是完整的操作系统，不可避免要占用所有资源。另外，多个容器可以共享资源，虚拟机都是独享资源。

体积小：容器只要包含用到的组件即可，而虚拟机是整个操作系统的打包，所以容器文件比虚拟机文件要小很多。

总之，容器有点像轻量级的虚拟机，能够提供虚拟化的环境，但是成本开销小得多。

Docker 属于 Linux 容器的一种封装，提供简单易用的容器使用接口。它是目前最流行的 Linux 容器解决方案。Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。有了 Docker，就不用担心环境问题。总体来说，Docker 的接口相当简单，用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。

8)容器化管理

图示：Kubernetes工作节点图

自愈: 重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。

弹性伸缩: 通过监控容器的cpu的负载值,如果这个平均高于80%,增加容器的数量,如果这个平均低于10%,减少容器的数量。

服务的自动发现和负载均衡: 不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes为容器提供了自己的IP 地址和一组容器的单个DNS名称，并可以在它们之间进行负载均衡。

滚动升级和一键回滚: Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。

所以基于k8s容器化的统一治理，一切变得很简单。让我们更方便的监控所有服务的状态、有统一的页面控制服务启停、并且快速的针对服务升级回滚。

9)用户管理

图示：用户角色权限关系图

图示：用户管理图

用户管理中的用户主要是功能系统的使用者，这些用户是一个一个的员工个体，这些个体往往从两个维度来进行划分：行政关系（部门架构)、业务部门（业务架构)。用户管理就是在此两个维度来给员工个体进行关联性的初步分群或者分组。按照行政部门或者按照业务线部门划分后，对应部门或者小组内的用户有着基本相似的系统功能使用需求和权限等级。

10)角色管理

图示：角色管理图

角色管理：角色往往是基于业务管理需求而预先在系统中设定好的固定标签，每个角色对应明确的系统权限，其所拥有的系统权限一般不会随意更改，并且角色也不会随着用户的被添加和被移除而进行改变，相较于用户管理而言更加稳定。

自动赋权：用户自动进入角色，如果角色与行政关系下的组织部门存在绑定关系，那么如果一个用户进入到该组织部门后，该用户会自动被加入到对应的角色中，并且拥有该角色所有的系统权限。

角色赋权：用户被添加进角色，业务是不断创新和发展的，随着业务的发展，会有越来越多的新的角色被设置和创建。

角色继承：角色权限的继承，权限可以是独有的，也可以是继承的。每个角色都有自己的权限集，角色继承其实也就是继承父系角色的权限，一般角色在继承其父系角色的全部权限的基础上增加拥有一些自己的权限。而系统角色继承往往存在于用户分级管理比较明确的团队或者公司；

角色互斥：角色包含的权限互斥，角色互斥的业务背景：当一个业务流程由于风控的原因，需要将其操作给划分成分开的几个步骤时，需要给这几个不同的步骤授权不同的角色，并且这些角色之间需要进行互斥。

临时角色：临时角色往往是针对特殊群体设置的，比如公司有特殊访问团队莅临，需要给这些特殊的客户一些临时身份来体验某些功能操作。那么把这些人添加到部门的组织架构中显然是不合适的，因为这些人只是临时的摆放者，不是企业员工；其次，这些客户需要体验的功能操作往往是横跨多个业务模块和产品线的（比较繁杂)，一般公司并没有现成的固定角色符合拥有客户所需的全部操作权限，因此需要给这些客户开设临时角色，并且支持给临时角色最大的权限选择空间。

11)权限管理

图示：权限管理图

权限管理更多是从功能菜单、功能操作、数据参数三个不同颗粒度等级来考量的。具体颗粒度的大小视公司结构和团队规模而定，如果不是业务属性一定要求将权限控制到非常精细的级别，其实就没有必要将权限的颗粒度拆分到具体某一项操作或者某一个按钮，毕竟后台产品的核心是业务管理平台，主要目标是辅助业务的管理和推进。

功能菜单权限：对于后台产品来讲，针对功能菜单来划分用户权限其实是比较粗颗粒度的一种管理方式，这种模式下用户一旦获得授权即可使用该菜单栏下的全部数据查看权限和功能操作权限。

功能操作权限：功能操作层级的权限相对于功能菜单会更为深入，这种情况下，不同角色的用户可以进入同一菜单页后台查看相同的数据字段信息，但是他们可执行的功能操作不同。

数据字段权限：数据字段层面是较细颗粒度的拆分，他会实现不同角色用户在进入同一菜单页后台时，可见的数据字段都有差异。比如销售人员进入某销售业绩管理后台时，可以看到自己的业绩提升数据，但是财务人员看到的是业务工单的费用字段，这些字段共存在一个菜单页中，只是受限于不同的角色权限而已。

12)操作日志

一、行为记录

详细记录用户在系统中的每一个操作，包括登录、退出、数据录入、修改、删除、查询等。明确操作发生的时间、操作者的身份信息（如用户名、用户角色等）以及操作的具体对象（如特定的数据表、文档等）。

对于关键操作，如涉及重要数据的修改或敏感功能的使用，进行重点标记和详细记录，以便后续审查。

二、追溯与审计

提供历史操作的追溯功能，方便管理员和审计人员在需要时查看特定时间段内的操作情况，了解系统的使用历史和数据变化过程。

支持按不同的条件进行查询和筛选，如按用户、操作类型、时间范围等，以便快速定位特定的操作记录。

为内部审计和合规性检查提供依据，确保系统的操作符合相关规定和政策。

三、安全监控

通过分析操作日志，可以及时发现异常操作行为，如频繁的错误登录尝试、大量的数据删除操作等，从而提高系统的安全性。对可能的安全事件进行预警，如发现可疑的操作模式或来自异常 IP 地址的操作，及时通知管理员采取相应的措施。

四、性能分析

操作日志可以提供关于系统使用情况的信息，帮助分析系统的性能瓶颈。例如，通过观察哪些操作耗时较长，可以针对性地进行优化。

​​​​​​​​​​​​​​13)接口管理

图示：API签名授权图

第三方接口中所有的数据字段要便于维护。数据接口中所有的数据表、字段都要有清晰的定义和说明。数据传输过程中产生的异常和错误日志，要以明文的方式分类输出。数据在传输过程中需要进行验证和加密，保证数据安全。为保证接口传输效率，在保证数据不丢失的前提下，可以考虑对传输的数据进行压缩。

在进行接口开发时，一般需要一个固定的返回样式，成功和失败的时候，都按照这种格式来进行统一的返回，这样，在与其他人进行接口之间的联调时不会显得很杂乱无章。

​​​​​​​14)流程引擎

流程引擎是一种软件系统，它能够解释、执行和管理业务流程的定义。流程引擎通常使用图形化的流程设计工具来创建流程模型，然后将这些模型转换为可执行的代码。

自动化业务流程：流程引擎可以自动执行一系列的任务和决策，从而减少人工干预和错误。它可以根据预设的规则和条件，自动路由任务、分配工作、发送通知等。

提高效率：通过自动化业务流程，流程引擎可以大大提高工作效率。它可以减少繁琐的手动操作，加快任务的处理速度，提高业务的响应能力。

增强合规性：流程引擎可以确保业务流程符合法规和内部政策的要求。它可以强制执行审批流程、记录操作日志、进行审计等，从而降低合规风险。

提供更好的客户体验：流程引擎可以优化业务流程，提高服务质量，从而提供更好的客户体验。它可以确保客户的请求得到及时处理，提供准确的信息和反馈，提高客户满意度。