一、kratos设计理念
这里主要讲解 kratos v2 的设计理念。
kratos 框架制定接口规范，然后通过插件来实现具体需求，实现自由定制、可插拔的微服务框架。
我们既可以选择 kratos 框架提供的插件，也可以自己定制实现相关插件，实现高度定制化。
也能整合相关 Go 的第三方工具。构建一个 Go 微服务的工具箱。
面向包的设计，参考了 Go 的基础库设计思想，包名按照实际功能划分，每个包都具有单一的职责，当用户不可见或者不稳定的接口放到了 internal 目录中
通过 Protobuf IDL 来构建应用程序。
kratos v2 版本中 API定义(http、gRPC定义)、gRPC Service、HTTP Service、请求参数校验、错误定义、Swagger API json、应用配置模版等都是基于 Protobuf IDL 来构建的：
二、kratos设计原则
- 简单：不过度设计，代码平实简单；
- 通用：通用业务开发所需要的基础库的功能；
- 高效：提高业务迭代的效率；
- 稳定：基础库可测试性高，覆盖率高，有线上实践安全可靠；
- 健壮：通过良好的基础库设计，减少错用；
- 高性能：性能高，但不特定为了性能做 hack 优化，引入 unsafe ；
- 扩展性：良好的接口设计，来扩展实现，或者通过新增基础库目录来扩展功能；
- 容错性：为失败设计，大量引入对 SRE 的理解，鲁棒性高；
- 工具链：包含大量工具链，比如 cache 代码生成，lint 工具等等；
三、kratos功能特性
- APIs（Protocol）：协议通信以 HTTP/gRPC 为基础，通过 Protobuf 进行定义；
- Errors：通过 Protobuf 的 Enum 作为错误码定义，以及工具生成判定接口；
- Metadata：在协议通信 HTTP/gRPC 中，通过 Middleware 规范化服务元信息传递；
- Config：支持多数据源方式，进行配置合并铺平，通过 Atomic 方式支持动态配置；
- Logger：标准日志接口，可方便集成三方 log 库，并可通过 fluentd 收集日志；
- Metrics：统一指标接口，可以实现各种指标系统，默认集成 Prometheus；
- Tracing：遵循 OpenTelemetry 规范定义，以实现微服务链路追踪；
- Encoding：支持 Accept 和 Content-Type 进行自动选择内容编码；
- Transport：通用的 HTTP/gRPC 传输层，实现统一的 Middleware 插件支持；
- Registry：实现统一注册中心接口，可插件化对接各种注册中心；
通过下面的架构图也可以看出来。
扩展性：
- 通过制定接口规范，用户可以通过实现接口来实现自己的定制功能，实现可插拔的插件功能。
- 中间件功能
四、框架架构设计
4.1 架构设计
(from: https://mp.weixin.qq.com/s/tA6Vm9MtjCfN9O95h0B3kQ kratos v2 版本演进)
- kratos 框架核心（core）：包括基础的 CLI 工具，内置的 HTTP/gRPC 接口生成工具和服务生命周期管理，并提供链路追踪、配置文件、日志、服务发现等组件（component）功能。这些组件都定义了相关接口，组件实现了这些接口。用户实现的自定义插件功能也是根据这些接口来实现的。
- Transport：传输层使用 HTTP/gRPC 。
- Application：用户编写的应用服务。
contrib plugins：
用户贡献的插件或叫第三方插件。根据定义的接口，实现的插件功能。有配置、日志、服务发现、监控等插件。
aegis：
服务可用性的一些算法，比如熔断、限流等。独立的项目，几乎没有依赖，跟不依赖 kratos。
command line tools：
工具链，用 CLI 命令来帮助用户快速生成各种代码，加快服务和应用的快速开发。具体可见：CLI 工具使用。
kratos cmd：为了进行快速开发，定义的一些 cli 命令。比如根据 proto 文件生成相应的 http/gRPC 的 Go 代码命令 -
kratos proto client。protoc plugins：proto 插件的一些命令。
看看 kratos v2.5.0 的代码结构：
参考
- kratos 开源社区：kratos 框架 v2 版本演进之路
- https://go-kratos.dev/docs/ kratos 官方网站
- https://go-kratos.dev/docs/getting-started/usage/ cli 工具