好久没有发表文章了，前两天刚好写一个微服务的方案，在这里与大家分享一下。
这篇文章只是一些概念的介绍，后续我会根据这个设计方案，将实现过程一步一步记录下来，与大家分享。
1 系统设计
1.1 总体框架
1.1.1 功能架构
微服务平台主要由服务支撑层、基础服务层、通用服务及业务服务层组成，系统总体功能架构图如下：
1) 基础设施
微服务平台的基础设施包括网络、存储、计算等硬件基础设施，为平台的运行提供基础保障。
2) 服务支撑层
服务支撑层为保证整个服务平台健康、高效运行提供支撑服务，包括服务注册与发现中心、配置中心、日志中心、监控中心、服务限流降级与熔断、微服务网关等支撑服务功能。
3) 基础服务层
基础服务层将平台通用的功能以服务的形式进行封装，为其他业务服务的实施提供基础服务，包括分布式缓存服务、分布式存储服务、搜索服务、消息队列服务、分布式事务服务、任务调度服务、统一认证中心、用户中心、组织机构管理、代办任务中心、流程管理中心等基础服务功能。
4) 通用服务层
通用服务层，是将一般业务功能开发都需要使用的功能进行封装，形成通用服务，提高开发效率，控制开发质量的一种方式。
5) 业务服务层
通过通用服务实现的业务逻辑部署在业务服务层，为前端应用提供服务。
1.1.2 逻辑架构
平台架构以Spring Cloud 微服务架构为核心进行构建，集成了Spring Cloud Alibaba Nacos 实现服务注册、发现与配置管理，集成Skywalking、 Elastic Logstash、Elastic Search、Elastic Kibana 实现日志中心功能、集成Prometheus、Grafana 实现监控预警功能、集成Spring Cloud Admin 实现微服务监控功能、集成Alibaba Sentiel 实现服务限流、降级与熔断功能，集成Spring Cloud Gateway 实现了微服务网关功能。
1.2 详细功能说明
1.2.1 服务支撑层
服务支撑层为保证整个服务平台健康、高效运行提供支撑服务，包括服务注册与发现中心、配置中心、日志中心、监控中心、服务限流降级与熔断、微服务网关等支撑服务功能。
1.2.1.1 服务注册、发现与配置
Spring Cloud Alibaba Nacos 是阿里巴巴公司的开源组件，Nacos 提供了一组简单易用的特性集，能够快速实现动态服务注册、发现、服务配置、服务元数据及流量管理功能，帮助企业更敏捷和容易地构建、交付和管理微服务平台，是构建以“服务”为中心的现代应用架构服务的基础设施。
- 服务发现和服务健康监测
Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI或一个独立的Agent TODO注册服务后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
Nacos提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos支持传输层 (PING或TCP)和应用层 (如 HTTP、MySQL、用户自定义)的健康检查。对于复杂的云环境和网络拓扑环境中(如 VPC、边缘网络等)服务的健康检查，Nacos提供了Agent上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助根据健康状态管理服务的可用性及流量。
- 动态配置服务
动态配置服务可以平台以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
- 动态 DNS 服务
动态 DNS 服务支持权重路由，让平台更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务使平台更容易地实现以 DNS 协议为基础的服务发现，以帮助消除耦合到第三方应用私有服务发现API上的风险。
1.2.1.2 服务监控中心
整个平台分布着大量的服务器、中间件、数据库、微服务组件，对他们的性能、运行指标、健康状况的监控就显得尤为重要。方案通过多种组件集成的方式提供了整个平台的可视化监控中心功能。
- 分布式链路追踪
随着业务的发展，平台中提供的服务会越来越多，服务之间的调用也会越来越错综复杂，一个请求可能会涉及多个服务，而服务本身可能也会依赖其他服务，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响，为此方案中通过集成Apache SkyWalking组件，来帮助我们快速定位和解决问题。
Apache SkyWalking包括了分布式追踪、性能指标分析、应用和服务依赖分析功能。SkyWalking 核心包括探针Probo、后台服务Backend、存储Storage、可视化UI 四部分组件，其中存储我们选用Elastic Search 企业级搜索服务来来存储监控日志信息。
SkyWalking 的探针只需要部署到要监测服务的服务器上，即可实现代码无侵入的方式收集服务相关日志信息。
探针收集到数据并进行格式转换后，将数据推送到后台服务，后台服务对收集的数据进行分析和聚和后存储到本方案选取的存储Elastic Search 上，以便可视化展示给最终用户。
- 服务器与组件监控
为了及时了解平台的健康情况，我们需要建包括服务器的CPU空闲率、CPU 使用率、CPU负载率、可用内存、内存使用率、文件系统空闲空间、网络上传、下载速率、磁盘IO情况，数据库吞吐量、连接情况、缓冲池使用情况、查询性能，Elastic Search 的查询索引性能、内存分配、垃圾回收情况、集群健康及节点可用性等多种指标。为此，本方案采用Prometheus组件实现平台的监控与报警功能。Prometheus 是一套开源的系统监控报警框架，他包含了多个独立的组件，其中有些组件是可选的，我们方案主要选择如下组件:
- Prometheus Server: 用于收集和存储时间序列数据;
- Exporters: 用于暴露已有的第三方服务metrics给Prometheus，本方案中主要用到了Node-Exporter、Oracle Exporter、 Mysqld-Exporter、ElasticSearch-Exporter、Redis-Exporter;
- Alertmanager: 从Prometheus server 端接收到报警后，会进行去除重复数据级分组操作，并通过邮件、短信等方式发出报警;
主要工作流程：
- Prometheus serve定期从配置好的exporters中拉取metrics;
- Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向Alertmanager推送报警信息;
- Alertmanager根据配置文件，对接收到的警报进行处理，发出告警;
- 在图形界面中，可视化显示采集数据;
1.2.1.3 日志中心
在各个微服务开发实现过程中，根据业务需要我们会设置一些埋点记录应用日志，比如用Log4j记录应用日志信息，以便我们对应用进行分析排查问题或做统计分析。为了能够实时、可视化的方式对日志进行统计、分析、查看，方案选用ELK开源组件实现日志中心功能。ELK核心组件包括：
- Elasticsearch：分布式搜索和分析引擎，具有高可伸缩、高可靠和易管理等特点。能对大容量的数据进行接近实时的存储、搜索和分析操作；
- Logstash：数据收集引擎。它支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置；
- Kibana：数据分析和可视化平台。通常与Elasticsearch配合使用，对其中数据进行搜索、分析和以统计图表的方式展示；
- Filebeat：一个轻量级开源日志文件数据搜集器。在需要采集日志数据的服务上安装Filebeat，并指定日志目录或日志文件后，Filebeat 就能读取数据，实时发送到Logstash进行解析，也可以直接发送到Elasticsearch进行集中式存储和分析。
另外，我们经常遇到一些需要将数据库中的数据同步到Elasticsearch中，以便提高查询效率、降低数据库服务器压力的情况，为了实现这样的功能通常有几个方案：
- 代码实现(双写)，针对代码中进行数据库的增删改操作时，同时进行elasticsearch的增删改操作；
- mybatis实现，通过mybatis plugin截取sql语句进行分析， 针对insert、update、delete的语句进行处理；
- AOP实现，根据制定的规则，如规范方法名，注解等进行切面处理；
- Logstash，利用Logstash支持动态的从各种数据源搜集数据的特性，可以进行数据的同步，只需要简单的配置就能将Mysql、Oracle等数据库的数据同步到Elasticsearch，但是Logstash的原理是每分钟进行一次增量数据查询，将结果同步到Elasticsearch，如果实时性要求不是特别高的情况建议使用此方案；另外，如果是只针对Mysql数据库的情况，可以利用阿里巴巴的Canal组件与Logstash相结合的方式实现实时数据同步到Elasticsearch。
1.2.1.4 服务限流、熔断降级
随着平台中微服务组件的不断增加，如何在其中一个或几个服务出现流量异常的情况下，保障其他服务能够正常运转，而不至于整个平台陷入瘫痪显得越来越重要。
阿里巴巴Sentinel 是面向微服务架构的轻量级流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性。
- 流量控制，流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。因此需要根据系统的处理能力对流量进行控制。Sentinel让我们从 控制资源的调用关系(例如资源的调用链路，资源和资源之间的关系)、运行指标(例如 QPS、线程池、系统负载等)、控制的效果(例如直接限流、冷启动、排队)等角度，进行灵活组合，从而达到想要的效果。
- 熔断降级，除了流量控制以外，及时对调用链路中的不稳定因素进行熔断也是 Sentinel 的使命之一。由于调用关系的复杂性，如果调用链路中的某个资源出现了不稳定，可能会导致请求发生堆积，进而导致级联错误。因此当检测到调用链路中某个资源出现不稳定的表现(例如请求响应时间长或异常比例升高)的时候，则对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联故障。
- 系统负载保护，Sentinel同时提供系统维度的自适应保护能力。防止雪崩，是系统防护中重要的一环。当系统负载较高的时候，如果还持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态，这个增加的流量就会导致这台机器也崩溃，最后导致整个集群不可用。针对这个情况，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。
1.2.1.5 微服务网关
平台中部署了很多微服务，这些微服务对外提供API接口以便客户端调用，每个微服务都有各自的地址、端口等信息，一个客户端可能需要访问很多不同的微服务去实现业务功能。这就需要客户端动态维护微服务的信息并与多个微服务之间进行身份验证工作，为了解决这些问题，就需要一个能够统一管理API 的网络关口，作为整个微服务平台请求的唯一入口，在网关层处理所有非业务功能(比如对调用微服务的客户端进行身份验证、记录日志、动态路由等)，本方案采用Spring 官方推出的 Spring Cloud Gateway 网关组件，具有如下特性：
- 是基于Spring Framework 5和 Spring Boot 2.x 的响应式、非阻塞式的 API；
- 动态路由：能够匹配任何请求属性；
- 可以对路由指定 Predicate(断言)和 Filter(过滤器)；
- 集成Hystrix的断路器功能；
- 集成 Spring Cloud 服务发现功能；
- 易于编写的 Predicate(断言)和 Filter(过滤器)；
- 请求限流功能；
- 支持路径重写。
客户端向Spring Cloud Gateway发出请求。如果Gateway Handler Mapping确定请求与路由匹配，则将其发送到Gateway Web Handler。此handler通过特定于该请求的过滤器链处理请求。而这些匹配是由路由断言Factory完成的，Spring Cloud Gataway包含了很多内置的路由断言Factories，这些断言都匹配HTTP请求的不同属性。多个路由断言Factories可以通过 and 进行组合使用。
主要内置断言Factory包括：
- After 路由断言Factory，After Route Predicate Factory采用一个参数—日期时间。在该日期时间之后发生的请求都将被匹配；
- Before 路由断言Factory，Before Route Predicate Factory采用一个参数—日期时间。在该日期时间之前发生的请求都将被匹配；
- Between 路由断言 Factory，Between 路由断言 Factory有两个参数，datetime1和datetime2。在datetime1和datetime2之间的请求将被匹配。datetime2参数的实际时间必须在datetime1之后；
- Cookie 路由断言Factory, Cookie 路由断言 Factory有两个参数，cookie名称和正则表达式。请求包含次cookie名称且正则表达式为真的将会被匹配；
- Header 路由断言Factory,Header 路由断言 Factory有两个参数，header名称和正则表达式。请求包含次header名称且正则表达式为真的将会被匹配；
- Host 路由断言Factory, Host 路由断言 Factory包括一个参数：host name列表。使用Ant路径匹配规则，.作为分隔符;
- Method 路由断言 Factory,Method 路由断言 Factory只包含一个参数: 需要匹配的HTTP请求方式;
- Path 路由断言 Factory,Path 路由断言 Factory 有2个参数: 一个Spring PathMatcher表达式列表和可选;
- Query 路由断言 Factory,Query 路由断言 Factory 有2个参数: 必选项 param 和可选项 regexp;
- RemoteAddr 路由断言 Factory,RemoteAddr 路由断言 Factory的参数为 一个CIDR符号(IPv4或IPv6)字符串的列表，最小值为1，例如192.168.0.1/16(其中192.168.0.1是IP地址并且16是子网掩码)
另外，Spring Cloud Gateway 可以与Oauth2、JWT集成实现在网关进行请求的身份验证与授权功能。
1.2.2 基础服务层
基础服务层将平台通用的功能以服务的形式进行封装，为其他业务服务的实施提供基础服务，包括分布式缓存服务、分布式存储服务、搜索服务、消息队列服务、分布式事务服务、任务调度服务等基础服务功能
1.2.2.1 分布式缓存服务
分布式缓存服务可将高频访问的数据，放入缓存中，可以大大提高微服务平台整体的承载能力，解决数据库服务器和web服务器之间的效率瓶颈。分布式缓存服务应支持高性能的Key-Value存储方式，支持string、list、hash、set、zset、hypeloglog等多种数据结构，支持主动过期和惰性过期的数据过期处理，支持volatile-lru、volatile-ttl等LRU策略，及内存管理、内容存储+磁盘持久化、主从复制等功能；在性能上应满足百万级QPS的资源调用，99.99%的可用性，毫秒级的核心请求响应时间，弹性扩展、易用等指标。
方案采用Redis来提供分布式缓存服务，可以完全满足上述要求：
Redis，是REmote DIctionary Server的缩写。是一个开源、基于C语言、基于内存亦可持久化的高性能NoSQL数据库，同时，它还提供了多种语言的API。它是一款由意大利人由Salvatore Sanfilippo所写的，依据BSD开源协议发行的高性能Key-Value存储系统(cache and store)。它通常被称为数据结构服务器，提供了一些丰富的数据结构，包括 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。Redis当然还包括了对这些数据结构的丰富操作。
1.2.2.2 分布式存储服务
分布式网络存储服务采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。分布式存储服务应支持文件存储、文件传输、跨机房架构、文件元数据管理、文件搜索、文件处理、文件版本管理、文件日志消息、大数据对接等功能，对外提供RESTfulAPI。
针对以上的需求我们采用MongoDB来应对。
MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。是介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
1.2.2.3 消息队列服务
消息队列服务可以为平台提供消息发布订阅、消息轨迹查询、定时(延时)消息、资源统计、监控报警等一系列消息服务，为平台提供异步解耦、削峰填谷的能力，同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性。
我们采用Apache Alibaba RocketMQ做为消息队列服务实现方案，Apache Alibaba RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点：
- 支持严格的消息顺序
- 支持 Topic 与 Queue 两种模式
- 亿级消息堆积能力
- 比较友好的分布式特性
- 同时支持 Push 与 Pull 方式消费消息
- 历经多次天猫双十一海量消息考验
对比其他主流消息队列组件主要优势有：
- 支持事务型消息(消息发送和 DB 操作保持两方的最终一致性，RabbitMQ 和 Kafka 不支持)
- 支持结合 RocketMQ 的多个系统之间数据最终一致性(多方事务，二方事务是前提)
- 支持 18 个级别的延迟消息(RabbitMQ 和 Kafka 不支持)
- 支持指定次数和时间间隔的失败消息重发(Kafka 不支持，RabbitMQ 需要手动确认)
- 支持 Consumer 端 Tag 过滤，减少不必要的网络传输(RabbitMQ 和 Kafka 不支持)
- 支持重复消费(RabbitMQ 不支持，Kafka 支持)
1.2.2.8 搜索引擎服务
通过搜索引擎服务将搜索引擎复杂的索引结构概念简单化、可视化和自助定制化。平台的上层业务应用可以通过控制台创建搜索应用，定制文档字段的结构和属性，包括字段名称、类型、分词方式、搜索属性等。搜索应用在运行过程中可以自由修改，满足业务快速变化的需求，缩短需求变更到上线的过程。
本方案中，我们基于Elastic Search实现搜索引擎服务，Elasticsearch 是一个实时的分布式搜索和分析引擎。它可以帮助用户用前所未有的速度去处理大规模数据、它可以用于全文搜索，结构化搜索以及分析。实现分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索，他是一个能够实现实时分析的分布式搜索引擎，并可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。
1.2.2.9 分布式事务
在微服务架构下，虽然我们会尽量避免分布式事务，但是只要业务复杂的情况下这是一个绕不开的问题，为了保证业务数据原子性、一致性，本方案采用阿里巴巴开源的一站式分布式事务解决方案中间件Seata, Seata能够帮助用户以高效并且对业务 零侵入的方式解决微服务场景下面临的分布式事务问题。
Seata整体事务逻辑是基于两阶段提交 的模型，核心概念包括以下3个角色：
- TM：事务的发起者。用来告诉TC，全局事务的开始，提交，回滚。
- RM：具体的事务资源，每一个 RM 都会作为一个分支事务注册在TC。
- TC：事务的协调者Seata-Server，用于接收我们的事务的注册，提交和回滚。
Seata有两种模式可使用分别对应不同业务场景:
- AT模式, 该模式适合的场景：
基于支持本地 ACID 事务的关系型数据库。
Java 应用，通过 JDBC 访问数据库。
- 一个典型的分布式事务过程：
① TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
② XID 在微服务调用链路的上下文中传播。
③ RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
④ TM 向 TC 发起针对 XID 的全局提交或回滚决议。
⑤ TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
- MT模式, 该模式逻辑类似TCC，需要 自定义实现prepare、commit和rollback的逻辑，适合 非关系型数据库 的场景
本方案参考了zlt的microservices-platform，在此表示感谢！！
未完待续......