面向开发

微服务框架

Spring Cloud

服务发现

Nacos

集中配置

Nacos

API 网关

Spring Cloud Gateway

进程间通信

OpenFeign: REST（ HTTP + JSON ）
Dubbo: rpc

Dubbo 可以与 Spring Cloud 较完美结合，理论上 OpenFeign 和 Dubbo 可共同使用，但在实际开发中，一般情况下要选择一种方式。
REST 跨平台，如果有使用异构语言的需求，这是最简洁的方案。基于文本的协议，序列化和反序列化性能较低，但一般情况下还好。需要要写文档，或者通过工具（例如 Swagger）生成文档，调用方需要脱离编码环境阅读文档，文档维护有一定成本。
Dubbo 性能更高，rpc 方案对开发来说也很方便，Service 不必包一层 Controller 即可对外提供服务。封装 API 层，接口情况一目了然，文档维护成本很低。
综上，个人倾向使用 Dubbo 进行服务间同步调用。主要还是从开发和维护的角度出发。

RocketMQ: 异步，消息队列
Spring Cloud 封装了 Spring Cloud Stream, 阿里提供了 Stream 基于 RocketMQ 的实现。

客户端负载均衡

Ribbon：使用 Feign 时使用
Dubbo 内建

断路器

Sentinel
Sentinel 阿里出品，支持主流框架，并自带Dashboard。

分布式事务

Seata
尽量通过设计绕开对分布式事务的依赖。

数据库

MySQL

ORM

MyBatis
使用原生 SQL，出现故障和性能瓶颈时，可采取的手段较多，较容易，DBA 和开发都可介入。一般情况下需要付出维护 xml / 注解的额外精力，有一些工具（e.g. 逆向工程和 MyBatis Plus）可用。
JPA
面向对象，只需要关心少量 Java 代码，开发十分便捷。一般情况下与 MyBatis 的性能差距其实没有很大。如果没有几倍的差别，不必纠结于性能，必要时使用视图和更高级的查询方式，比如 ElasticSearch。JPA对数据查询封装了一套基于JAVA的语法，可以屏蔽底层数据库的差异，但带来的是学习成本。JPA也支持原生 SQL。

Spring Data JPA 与 Spring 的理念一致，封装统一接口，屏蔽差异，解决一个问题的方案永远不止一种。从这个角度来说，不同程序员的知识储备不同，选择的方案不同，团队协同开发时学习成本增加。MyBatis 则没有这个问题，只需要学习 SQL 这一门大家都会的 DSL，和基本 API 的使用即可。

建议 MyBatis。

缓存

Redis

统计及高级检索

ElasticStack

安全框架

Spring Security
原理简单，基于一系列 filter 实现不同的策略，但代码复杂。
自研
OAUTH 2.0 实现 SSO
JWT，无状态（实现高阶功能时也会在服务器保留少量状态）

反向代理及静态服务器

Nginx

面向运维

TODO

版本说明

组件	版本
Spring Cloud	Greenwich （目前是SR4）
Spring Cloud Alibaba	2.1.0 或最新稳定版
Spring Boot	2.1.x （目前是2.1.11）
其他	满足以上版本的最新稳定版