微服务框架 - 模块需求篇

用户头像
superman
关注
发布于: 2020 年 08 月 14 日

概述

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

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

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

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



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



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,无线

多种认证支持:认证通道,统一认证拦截

日志:请求参数规范,日志。

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

服务熔断:不可用服务熔断,恢复

服务路由:根据规则路由到具体服务,路由规则刷新。

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

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

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

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



7: 容器化与devops

7.1 问题

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

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

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

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

 

7.2 方案

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

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

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

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



8:统一服务治理平台

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



发布于: 2020 年 08 月 14 日 阅读数: 60
用户头像

superman

关注

还未添加个人签名 2018.07.20 加入

还未添加个人简介

评论

发布
暂无评论
微服务框架-模块需求篇