概述

从微服务各个模块的需求侧，及功能设计，实践选型与落地三个方面理解微服务框架。

问题---为什么需要-why

概念架构：根据需求特点设计--how

解决方案：实际实现，可有多种具体实现。-what



===概念===

分布式系统与微服务区别

分布式系统是为解决应对多个访问者（高并发），数据量大（海量），高可用，采用多个节点配合提供功能。

微服务：是服务化的一种升级，从单体-服务化-微服务，是一个系统业务复杂后，对业务拆分的手段。



实施微服务

服务拆分（抽象，拆分，DDD）,服务管理：api网关，PRC,服务注册，服务治理（熔断，限流），日志，监控。 Devops(测试与部署-容器化）

========



本篇：从各个主要模块面对的问题出发，分析其需要的什么方案来解决这些问题。



1：服务配置

1.1 问题

     服务配置的重用与统一维护

如何保证服务的多个节点间配置的一致性。

     如何保证不同服务间共享配置的一致性。

     如果采用多个地方分散放置配置，多种方式配置会导致配置混乱，修改调整故障频发。

配置不规范：

格式不统一，不标准。

修改配置成本高

寻找配置，修改到生效，可能需要重新发布。

如果配置放在多个位置，需要修改多处，还有可能遗漏

配置的历史信息

如何获取配置历史修改信息，

审计追溯：谁什么时间修改的配置

1.2 方案

采用统一的规范，与集中存储管理的配置中心，规范与统一配置。

配置规范

    要求：既不重复配置，也不命名冲突，更能见名知义。

    相同的用途用一个配置项

    配置项命名统一规范：名称规范，层级与分类。

                看到配置名就能猜出用途

                相同归属的命名类似：比如连接db的命名统一 db.xxx.xxx

                相同应用的：应用名.XXX.XXX

                配置的值作用相似用相同的取值规则。enable:1 表示可用。flag:1表示开

集中配置

      一个配置多处使用，一处修改全部生效。   

     优点

     1> 不同服务间的共性配置共用：一次配置，多个地方使用

     2>  解决相同服务多个节点的统一配置

     3> 配置在配置中心统一修改，保证各个节点一致性。

     4>不同环境共用与差异化配置

2：通信框架

2.1 问题

         服务间的远程调用如何进行

         调用的服务在哪里

         服务的接口是什么

         多个服务提供者如何负载

         远程调用的共性问题：  服务治理相关

2.2 方案

选择协议，建设|选择 通信框架     

1：根据业务特点选择通信协议：http,rpc

2：建立通信框架：方便服务方与调用方使用，隔离远程，多节点等复杂性。

说明

http与rpc的特点比较

         http对客户端集成友好，通用协议，不需要三方依赖，也语言无关。

         rpc性能高，接口友好。

         内部服务间调用多用rpc。给第三方提供的服务多用http.

         http方便扩展新功能-接口不用更新。wiki上描述即可。

    通信框架实现内容     

         通信相关：协议，序列化，通信安全，是否支持多协议。

                          http,rpc(dubbo,grpc)等,支持TLS,HTTPS,

                          支持压缩，消息体加密等

        服务描述：api如何定义，wiki（http rest模式）,跨语言的接口定义生成多种语言接口

（grpc,thift）,语言特定接口定义

       服务治理相关：

             服务注册发现

             服务负载

             其它：重试，健康检查等

3：服务治理

服务治理目的：保证在各种场景下系统尽量稳定运行，可用。

3.1 需求

         服务端故障：单节点，IDC,集群

         消费者应对故障：防止被级联拖垮

         服务灰度升级

3.2 方案

       多维度故障检测与处置

 1:健康检查

管理谁可用谁不可用

               注册中心判断

               消费者判断

               故障摘除与恢复

  2:服务端故障处置

        单节点：故障节点摘除（注册中心|消费者摘除），重启

        IDC:流量切换(RPC分组|DNS解析）

        集群：防止流量冲击---限流与降级

  3:客户端调用失败处理

                 熔断与重试

                 失败策略：快速失败，重试，稍后重试，失败通知-查询与重试。

   4:灰度升级

                版本管理，路由控制

4:服务监控

服务监控是帮助发现问题，服务治理解决问题，保证平稳运行，日志追踪是出现问题后辅助定位问题。

4.1 需求

发现用户使用的异常与操作习惯

发现系统业务指标与趋势

服务运行情况

基础设施的运行情况

4.2 方案

多维度的监控与多角度展示监控结果（部分功能归于系统统计功能-指导运营）

多维度监控

用户端监控：收集用户使用信息，包括正常与异常。

业务监控：用户或公司运营关注的核心业务指标

服务监控：请求量，响应时间，异常，服务内部处理指标（Metrics）

基础组件监控：缓存，db,消息队列,文件系统等。

基础设施监控：系统内存，IO,CPU,网络监控。

统计与展示

维度：按时间段，机器，机房，服务统计

指标：请求量，响应时间，失败数，平均，峰值，趋势。

显示：折线图，饼图，柱状图等

监控系统与其他系统关联

与日志系统日志追踪系统关联

     异常问题可调整日志系统定位

与报警关联

      指标异常报警

5：日志收集与调用追踪

日志作用

      帮助研发排查问题

      日志中收集后统计相关指标，用于异步的分析。

5.1 问题

问题排查如何进行，服务分散到多个节点，跨越多个服务，如何可以方便的排查问题

不同机器不同服务日志的收集方便统计分析

5.2 方案

日志归集：将日志收集到一起，提供统一的获取查询   

日志追踪：将一次请求的调用链路上的日志按规则串联与关联，方便问题定位。



6：网关

6.1 需求

目标：对外部，多种设备接入提供统一的入口，屏蔽内部多种服务。

主要功能需求

• 反向路由：将外部请求转换为内部服务的请求

• 安全认证：防止非法访问

• 限流熔断：

• 日志监控：日志监控



6.2 方案



结构

设备--->负载均衡--->网关（多个）---->微服务

要求

网关一般不做具体业务功能的实现

多协议支持：多种接入设备支持多种协议，http,grpc 等

可以提供多个类型的网关提供给不同使用方：内部，第三方，开放平台，H5,无线

多种认证支持：认证通道，统一认证拦截

日志：请求参数规范，日志。

流量限制：根据服务指标进行流量限制

服务熔断：不可用服务熔断，恢复

服务路由：根据规则路由到具体服务，路由规则刷新。

无效请求拦截：请求参数无效可统一拦截。

请求参数规范化：各种协议请求参数按内部标准规范化

部分服务发现与负载也放在网关层。

对多个服务的聚合服务，一般不建议放在网关-聚合多个服务本身就是一种业务逻辑了，可以在基础服务上建立聚合服务层。网关访问聚合服务层。



安全

授权认证中心

服务的api分为两类：内部服务间相互调用， 提供给外部使用的服务（开放平台等）

oauth2



7: 容器化与devops

7.1 问题

• 拆分后服务众多，迭代快导致打包，测试，发布频繁，如何对发布的基础环境进行保障，避免不同服务的相互影响。

• 众多服务的基础设施如何管理，如何隔离

• 服务需求的弹性扩张与基础设施的高效利用的矛盾

• 团队微服务化后基础设施管理平台化需求

7.2 方案

devops 与容器化实现快速的开发，部署，测试，集成，部署

devops 实现整个流程的敏捷化与自动化，容器化是部署阶段的的一种手法。

对基础设施的抽象与隔离是虚拟化解决的问题(在硬件上进行隔离），容器化在原来虚拟化的基础上的进一步发展，在操作系统上进行隔离（同一个操作系统），更轻量，消耗更低，启动更快。使发布程序更快。

基于容器的调度k8s与微服务架构相互成就。火热的云原生概念。



8：统一服务治理平台

      运维研发一体 ，集成服务治理与服务运维