转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：
根据保险行业发展趋势，目前保险交易已经呈现高频化、碎片化、场景化等特点，对系统的处理能力、容量、业务连续性、需求相应速度、运维响应速度提出了更高的要求。业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负，敏捷开发和快速交付无从谈起。
本次实施目标为建设满足XXX保险公司业务需求的微服务管理平台和配套工具规范，包括：微服务开发框架，微服务登记平台，微服务管理平台等，能够支撑微服务的开发、运行生命周期管理，进而更好的支持业务与技术的发展与创新。
目录：
一、项目背景与目标
二、微服务平台架构设计
三、微服务调用关系
四、微服务访问鉴权设计
根据保险行业发展趋势，目前保险交易已经呈现高频化、碎片化、场景化等特点，对系统的处理能力、容量、业务连续性、需求相应速度、运维响应速度提出了更高的要求。业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负，敏捷开发和快速交付无从谈起。
客户面临的问题主要是：
基于单体架构或SOA架构的应用无法适应业务模式创新的需要
缺乏微服务应用的统一技术标准与体系架构
微服务架构试点项目反应出对于服务的管控、治理亟待提升
客户微服务平台定制的目标，是建设满足新形势下保险业务需求的微服务管理平台和配套工具规范，能够支撑微服务的开发、运行生命周期管理，这主要包括：
微服务开发框架：一个供开发微服务的服务框架基座；
微服务登记平台：进行微服务设计、开发、变更、版本、订阅、下架等全生命周期管理；
微服务管理平台：进行微服务运行时管理，包括服务注册、服务发现、配置中心、网关、负载均衡、认证鉴权、熔断降级、监控等功能。
基于微服务架构的企业分布式应用平台，从集成开发工具、服务运行环境、应用管理监控、外部渠道接入等维度来划分，其功能架构如图所示，包括SDK&规范、注册中心、配置中心、监控中心、认证中心、API网关、服务运行环境、管理平台、登记平台等部分。
微服务平台逻辑架构
微服务平台概念模型
结合客户的实际情况，微服务平台的概念模型定义如下：
注册中心：支持一个环境内所有域下所有微服务的注册
配置中心：支持支持一个环境内所有域下所有微服务的配置
APM：支持一个环境内所有域下所有微服务的APM监控
断路器监控中心：支持一个环境内所有域下所有微服务的断路器监控，支持按每个版本查看
日志中心：支持一个环境内所有域下所有微服务的日志收集、查看
域：对应完整的业务域，比如车险域
网关：网关分为外部网关和内部网关。外部网关部署在DMZ区，用于把API对外网暴露；内部网关用于跨系统间的API调用
系统：对应实际的业务系统，每个域有多个业务系统
应用：对应业务系统中的业务模块，每个业务系统有多个应用
微服务：每个应用有多个微服务
微服务版本：每个微服务可以有多个版本，其中可以有多个上线运行版本
API：每个微服务版本提供的API
实例：每个微服务版本的运行进程
微服务之间的调用关系分为系统内部和跨系统两种场景：
1、系统内部的微服务之间调用
采用直连方式，微服务多实例部署时，调用者采用客户端负载均衡器（如Netflix Ribbion）。
2、跨系统的微服务之间调用
跨系统的微服务调用通过API网关进行中转，服务提供者需要在API网关上配置路由，然后在API Store中发布API；
服务消费者通过API Store订阅需要的API并获得订阅码，然后携带订阅码调用所订阅的API；
API Store支持订阅审核流程，服务提供者可以对消费者的订阅请求进行审核。
注：API Store是为客户定制的管理服务发布与订阅的模块，这里不做展开描述。
在实际业务场景中，微服务提供者运行期存在多版本共存的情况，所以API网关和微服务SDK支持微服务多版本路由策略：
客户端请求头指定调用目标服务版本
支持灰度版本策略：可以设置针对特定的一组调用者允许或不允许访问灰度版本（即黑白名单），即灰度版本导入部分客户端流量
支持灰度版本在线热切换成正式版本
服务的调用过程包括服务发布与服务消费的过程。
在不同的服务调用场景中，API网关和服务提供者需要对消费者的身份进行认证、对服务调用进行鉴权。
API网关负责校验客户端订阅码的合法性（调用API鉴权服务进行鉴权），支持黑白名单配置；微服务提供者（SDK）负责校验客户端（系统内部服务或者API网关）身份的合法性。
微服务访问鉴权设计
1）服务消费者通过API网关调用服务提供者的API时，需要在请求头中携带订阅码
2）API网关根据请求头中的订阅码，调用鉴权服务校验请求的合法性，鉴权失败则拒绝非法请求
3）API网关鉴权成功后，删除请求头中的订阅码，避免泄露服务消费者的安全信息给服务提供者，并在请求头中添加API网关标识，然后根据当前路由规则转发到后端某个API服务提供者实例上
4）服务提供者接收到来自API网关或者系统内部其他微服务的调用请求，获取请求头中的客户端标识，根据这个标识从服务注册中心获取客户端实例列表，比较此次请求的来源是否在实例列表中，验证此次请求是否来自合法的消费者。
下面是Java客户端调用示例，订阅码等调用所需的参数可以在application.yml (application.properties)或配置中心上配置，微服务SDK开发工具包中已经封装了请求头关于鉴权的处理。
Java客户端调用示例
以上便是通过某保险公司微服务平台实施案例，分享了微服务架构下的服务调用与鉴权的全部内容。
精选提问：
问1：“服务的调用过程包括服务发布与服务消费的过程”，这里讲了“服务消费的鉴权”，那“服务发布”有需要鉴权的么？
答：API发布的时候可以设置是否需要审批，服务消费者订阅API的时候，API Store会根据是否需要审批的设置，判断是否交由服务提供者进行订阅审批，审批通过后才算是订阅成功，才能进行调用。服务发布本身现在是通过API Store的用户权限控制，由提供者的管理员进行发布。
问2：系统A不允许访问系统B的服务1，但可以访问系统B的服务2，而服务2走系统内部直接访问服务1，那么：在系统A被授权或访问服务2的时候，API Store或者API网关会提示风险么？
答：不会提示，系统B的服务2调用自己系统内部的服务1是不会被限制的，网关鉴权只关注系统A调用系统B的服务是否合法。
关于作者：李忠文，普元开发工程师，普元DevOps核心成员之一。曾参与兴业银行、上海大众、北京海关、交行卡中心、中国银联等项目
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。
