jfinal 与 spring cloud 是不同的领域，前者是 web + orm + aop + template engine 框架，后者是微服务技术栈，无法相比较

jfinal 要比较的话，是要同 spring boot 比较，其中的 web 部分属于同类，但 spring boot 的 orm 与 template engine 等模块都是集成的第三方，jfinal 这些功能都是自己手写，确保极简与高品质

关注一个技术是不是很老，还不如关注一个技术是不是最好用，如果一个很古老的技术直到现在都很好用，恰恰验证了其优秀

你可以试用一下 spring cloud ， 买本书看一看，应用成本非常之高，对于绝大多数项目用用集群就搞定了，根本用不上 spring cloud

spring cloud 是对很多种技术的一个整合性的技术栈，是个大杂汇，我从来没见过哪家公司真正能将之用起来的，这个技术栈涉及面非常广：
服务治理整合的 Eureka
客户端负载均衡整合的 Ribbon
服务容错保护整合的 Hystrix
声明式服务调用整合的 Feign
Api 网关整合的 Zuul
消息总线整合的 RabbitMQ 或 Kafka
分布式服务跟踪整合的 Sleuth
web 框架整合的 spring boot

其它功能的整合不再赘述，总之用到啥就得去整合

spring 那套东西与 jfinal 基本是相反的路，jfinal 做小而精，核心功能都是自己写，保持极简设计，学习成本低，spring cloud 与 spring boot 绝大部分功能都是去整合，走的大而全的路

上面谈到的这些技术， 你要用上 spring cloud 的步骤大致如下：
1：将你的项目先拆分成小型的项目，也就是所谓的微服务。根据项目大小去拆分，有些人一个项目能拆成十多个微服务

2：拆分之前各模块的调用是方法调用，拆分后变成了服务间调用，一般是走 http、rpc 等机制，不仅徒增很多开发成本，而且会拉低性能，服务间通信的效率比方法调用要低得多

3：将前面谈到的一些技术用到的软件安装、配置、部署起来

4：按照 spring cloud 各项技术的要求，将第一步拆分的项目分别部署起来

这么多的技术全部跑起来并且进行维护的成本是极高的，99.9% 的公司顶多弄弄集群就搞定的事，根本不需这么来弄

剩下来有需要的是有钱、有人的大公司，而大部分大公司都有自己的一套分布式解决方案，仍然也用不上这些东东，这就是 spring cloud 的尴尬之处

最后，由于 spring cloud 的应用成本如此之高，未来分布式的趋势是走 k8s + docker + rancher 的技术路线，不仅成本低，而且对于应用来说是透明的，也就是说你开发的项目根本不用管分布式的事情，全交给更底层的容器来解决

jfinal 早在去年就思考过要不要介入微服务，也正由于 k8s + docker + rancher 这类技术路子更适合未来分布式的方向，所以 jfinal 才没出手微服务的事

一定要记住：选择不做什么比做什么更重要

感觉微服务是搞技术咨询的人搞出来的一个概念，能解决一些问题，但同时也把问题弄得更复杂了。

@JFinal 波哥威武 , 感谢科普

很赞同波总的观点，实际当中绝大多数公司业务根本没到那种量级，绝大多数都是在跟风，SpringCloud学习成本实在是太高了，对硬件要求也很高，8g内存开发会感觉有点吃力，跑时间长了，电脑可能慢的有点难以忍受。

@JFinal 现在好像微服务更火了。。