微服务实践分享与探讨

服务调用关系

API网关优缺点

• 简化沟通方式
  API网关对所有微服务提供单一的访问点
• 安全性
  对客户端隐藏了服务发现和服务版本
  阻止大规模攻击，包括SQL注入，XML解析漏洞和Dos攻击
  验证token,certificates和其他credentials
• 混合通讯协议
  API网关翻译并支持不同的通讯协议
• 调用频率，跨域，缓存配置
• 需要额外的配置
• 需要管理路由的配置
  

常见的微服务组件及概念

• 身份认证
  用户、客户端、资源交互过程中的身份认证授权框架

• 服务注册
  服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。

• 服务发现
  服务调用方从服务注册中心找到自己需要调用的服务的地址。

• 负载均衡
  服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。

• 服务网关
  服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。

• 配置中心
  将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。

• API 管理
  以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。

• 集成框架
  微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。

• 分布式事务
  对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。

• 调用链
  记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。

• 支撑平台
  系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。
  现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

身份认证架构的演变

开发过程中常见的交互

• 浏览器与Web应用程序通信, B/S
• 浏览器与web API通信 B/S
• 基于浏览器的应用程序与Web API通信（有时是独立的，有时代表用户） electron node-webkit H/S
• 桌面程序程序与Web API通信 C/S
• 后台Service与web API通信 S/S
• Web API与Web API通信（有时是独立的，有时代表用户）S/S
  
  
• Users 用户
  使用客户端访问微服务资源的人。
• Clients 客户端
  请求令牌的软件，用于验证用户（请求身份令牌）或访问微服务的程序（请求访问令牌）。
  如：Web应用程序，本地移动或桌面应用程序，SPA，服务器进程等。
• Resources（微服务） 资源
  想要使用IdentityServer保护的资源 - 您的用户的身份数据或API。
  （每个资源都有1个唯一的名称 - 客户端使用这个名称来指定他们想要访问的资源。）
• Identity Data 身份资源
  用户的标识符，可以包含其他身份数据。
• Access Token 访问令牌
  访问API资源的令牌。包含有关客户端和用户的信息（如果存在）。API使用该信息来验证授权并判断是否可访问其数据。
  附上：微软Azure AspNetCore微服务实战PPT 链接,密码: 97mg