面向开发
微服务框架
- 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） |
| 其他 | 满足以上版本的最新稳定版 |
网友评论