1. 微服务概览
1.1 单体架构
最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。
应对的思路：化繁为简，分而治之。
1.2 微服务起源
大家经常谈论的是一个叫SOA(面向服务的架构模式)，它和微服务又是什么关系？你可以把微服务想成是SOA的一种实践。
- 小即是美：小的服务代码少，bug也少，易测试，易维护。
- 单一职责：一个服务也只需要做好一件事，专注才能做好。
- 尽可能早地创建原型：尽可能早的提供服务API，建立服务契约。
- 可移植性比效率更重要：服务间的轻量级交互协议首要依然考虑兼容性和移植性。
1.3 微服务定义
围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。
微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署， 使得整个系统变得清晰灵活。
优点：
原子服务
独立进程
隔离部署（避免相互影响，按需进行分配资源）
去中心化服务治理（数据去中心化，技术去中心化）
缺点：
- 基础设施的建设、复杂度高。
- 需要使用RPC或者消息传递，来实现进程间通信，考虑消息传递中速度过慢或者服务不可用等局部失效问题。
- 分区的数据库架构，需要更新不同服务的不同数据库，涉及到分布式事务的问题。
- 测试分布式应用，也会变得复杂。
- 对运维设施要求较高。基础设施需要自动化，日志采集，监控数据采集，告警，CICD，K8S 等。
1.4 微服务构建
kit：一个微服务的基础库（框架）
service：业务代码+kit依赖+第三方依赖组成的业务微服务
RPC+ 消息队列：轻量级通讯
基础设施自动化：无自动化不微服务。
可用性兼容性设计：隔离，超时，限流，降级，重试，负载均衡。
1.5 微服务拆分
参考：https://www.liuvv.com/p/cc26c72d.html 分久必合，合久必分。
按照业务组织服务。
按业务能力组织服务的意思是服务提供的能力和业务功能对应。比如：订单服务和数据访问服务前者反应了真实的订单相关业务，后者是一种技术抽象服务不反应真实的业务。所以按微服务架构理念来划分服务时，是不应该存在数据访问服务这样一个服务的。
如果可以闭环的解决一个用户场景，那么它应该是一个微服务。
还可以根据访问频率进行区分划分，将用户高频访问的部分划分为一个服务。
CQRS: 将应用程序分为两部分：命令端和查询端。命令端处理程序创建，更新和删除请求，并在数据更改时发出事件。查询端通过针对一个或多个物化视图执行查询来处理查询。
2. 微服务设计
2.1 API Gateway
参考：https://www.liuvv.com/p/1ea51f9f.html
如果对外暴露了一批微服务， 但是因为缺乏统一的出口面临了不少困难客户端到微服务直接通信，强耦合。协议不利于统一，各个部门间有差异， 需要端来兼容。统一逻辑无法收敛，比如安全认证、限流。 我们之前提到了我门工作模型，要内聚模式配合。
BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的API，方便无线设备接入访问后端服务。
跨横切面(Cross-Cutting Concerns)的功能，需要协调更新框架升级发版（路由、认证、限流、安全)，因此全部上沉，引入了API Gateway，把业务集成度高的BFF层和通用功能服务层API。在新的架构中，网关承担了重要的角色。
随着功能复杂增加，也拆分成多个BFF。BFF的开发人员可以更加专注业务逻辑交付，实现了架构上的关注分离。
流量路径：移动端 -> API Gateway -> BFF -> Mircoservice。
2.2 安全和认证
对于外网的请求来说，我们通常在API Gateway 进行统一的认证拦截，一旦认证成功，我们会使用Header方式通过RPC元数据传递的方式带到BFF层，BFF获取后把身份信息注入到应用的Context中，BFF到其他下层的微服务，建议是直接在RPC Request中带入用户身份信息 (UserID)请求服务。
在内网主要看安全级别一般有三种：
- Full Trust：假定内网服务之间是安全的，在内网裸奔
- Half Trust：内网服务之间需要进行认证鉴权，但是不需要所有的都进行加密
- Zero Trust: 零信任，任务内部网络是不安全的，类似公网，所有的请求通过身份认证鉴权之后，都需要通过安全加密，防止被嗅探
3. 参考资料
- https://lailin.xyz/post/go-training-01.html
- 《极客大学-Go进阶训练营》
