微服务起源

单体应用的缺点

• 单体应用复杂
• 应用无法拓展
• 可靠性低
• 敏捷开发和快速部署无法完成

由此产生微服务

一切争端的开始

微服务的演变

微服务本质上是对面向架构的模式(SOA)的一种实践

微服务的特点:

• 小即是美
• 单一职责
• 尽可能早创建原型
• 可以执行比效率更重要

微服务的定义

围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活

核心： 化繁为简 分而治之

优点：

• 原子服务
• 独立部署
• 隔离部署
• 去中心化服务治理

缺点：

• 基础设施建设复杂度高
• 分布式服务间通信机制变得复杂 对不可用节点服务处理变得更加复杂
• 分布式的分区数据库 对分布式事物等需要做对应的复杂处理
• 测试整体的微服务架构复杂
• 服务间的依赖 局部升级可能影响整体

微服务设计思路

组件服务化

• kit:一个微服务的基础库（框架）
• service: 业务业务代码+kit依赖+第三方组件的依赖
• RPC+message queue: 轻量级通讯

按业务组织服务

事实上传统应用设计架构的分层结构正反映了不同角色的沟通结构。所以若要按微服务的方式来构建应用，也需要对应调整团队的组织架构。每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面的技能

去中心化

• 数据去中心化
• 治理去中心化
• 技术去中心化

基础设施自动化

• ci/cd
• auto testing
• 在线监控

服务兼容性设计

发送时要保守，接收时要开放。按照伯斯塔尔法则的思想来设计和实现服务时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍冗余数据，保证兼容性。

• 负载均衡
• 超时控制
• 负载保护
• 隔离
• 限流
• 降级
• 重试
• 熔断

微服务设计

API GATEWAY

backend for forntend BFF 可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的 API，方便无线设备接入访问后端服务

微服务的划分

微服务的安全

服务发现 & GRPC

GRPC

• 多语言：语言中立，支持多种语言。
• 轻量级、高性能：序列化支持 PB（Protocol Buffer）和 JSON，PB 是一种语言无关的高性能序列化框架
• 可插拔
• IDL：基于文件定义服务，通过 proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub
• 移动端：基于标准的 HTTP/2 设计，支持双向流、消息头压缩、单 TCP 的多路复用、服务端推送等特性，这些特性使得 gRPC 在移动端设备上更加省电和节省网络流量。
• 服务而非对象 消息而非引用：促进微服务的系统间粗粒度消息交互设计理念
• 负载无关的：不同的服务需要使用不同的消息类型和编码，例如 protocol buffers、JSON、XML 和 Thrift。
• 流：Streaming API。
• 阻塞式和非阻塞式：支持异步和同步处理在客户端和服务端间交互的消息序列。
• 元数据交换：常见的横切关注点，如认证或跟踪，依赖数据交换。
• 标准化状态码：客户端通常以有限的方式响应 API 调用返回的错误

服务发现

• 客户端发现：
  直连 比服务端服务发现少一次网络跳转 Consumer 需要内置特定的服务发现客户端和发现逻辑

• 服务端发现：
  Consumer 无需关注服务发现具体细节 只需知道服务的 DNS 域名即可 支持异构语言开发 需要基础设施支撑 多了一次网络跳转 可能有性能损失

• 服务网格 service mesh:
  通过sidercar 方式隐式的支持服务发现（待补充）

多集群 & 多租户

多集群

为了保证服务的可用性 已经对异常情况的预处理 使用多集群的方式提高系统的可用能力

多租户

在一个微服务架构中允许多系统共存是利用微服务稳定性以及模块化最有效的方式之一 这种方式一般被称为多租户（multi-tenancy）

通过不同的租户区分不同的业务功能：

• 红蓝发布
• 灰度测试
• 模块测试

多租户的概念较为模糊
思考？ 多租户中是怎样实现在上下文中传递多租户信息的?