基于微服务架构的企业分布式应用平台，从集成开发工具、服务运行环境、应用管理监控、外部渠道接入等维度来划分，其功能架构如图所示，包括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客户端调用示例
以上便是通过某保险公司微服务平台实施案例，分享了微服务架构下的服务调用与鉴权的全部内容。