前端三大 MVVM 框架论原理都是半斤八两的，我不认为他们的性能会有数量级的差别，所以我认为你们的前端压根就没抓住问题根本，所以你们用 Vue 多半还是会撞上这个南墙

ROR 是目前最接近声明式编程语言思想（ tel me what you want，not how to do ）的 Web 框架，如果你理解了它的思维你写起来会非常爽（号称最理解程序员）。缺陷就是速度特别慢，外加语法糖太多了，导致你理解别人的代码就有困难。再就是声明式如果搞不定问题的时候，你就要头疼了

@lihongjie0209 当然用了，但是你反向代理解决不了这个问题

@tabris17 你如何用配置解决

@imn1 想过这个方案，然而还是无法接受，太丑陋了，引入了中间环节，更容易出问题

@nfroot 相对路径在开发中很容易出错，我现在是能不用，就不想用上下文路径

Vue 赶了好时间，React 入门门槛太高，angularjs 自己作死吓跑了一堆使用者到底现在气都没缓回来

别想了楼主，微软现在所有的精力全部在云上，KV 人家有，而且性能还很不错，叫 Cosmos DB,想用吗？对不起，请上 Azure，不提供单机版本，甚至服务器版本的也不提供。现在真的是 Windows(Server)个人操作系统最黑暗的时代，所以现在我是能不能上 windows 就不上 windows

@lniwn flash 是自己作死的

iphone 目前唯一的优势估计也就是权限管理了

@beneo 另外，就算不做分析，联表查询仍然是很常见的现象，Hibernate 和 JPA 搞联表真心和吃翔一样。哪怕最简单的联表查询也是

@choice4 感觉没写错，你单数据库，单事务管理器，确认一下是否能回滚

@beneo 你起码是在 1 个中型规模以上的公司，或者专门以大数据为业的行业，去掉这两点外，大把的中小型公司压根就不上 Hadoop 之类的玩意。有钱的公司还是少数，穷逼公司是多数

@choice4 不回滚？你确定你的数据库事务设置没问题吗？变成单数据库，单事务管理器，同样的 serviceImpl 代码看是否回滚

@choice4 我明白了，你的事务管理器不止一个，那你必须明确的在 service 层的 @Transactional 里指定特定的事务管理器，否则就出错

哎，现在学编程的基本都不会教历史了，也没人有兴趣去钻研。总体来说吧，很多年前，Sun 还在世的那个年代，在度过了早期用 C++写 Html 解析器的蛮荒时期后，有一批最早的脚本程序进入了 cgi 时代，此时的 Sun 决定进军这个领域，为了以示区别并显得自己高大上，于是研发了 servlet 标准，搞出了最早的 jsp。并给自己起了个高大上的称号 JavaEE （ Java 企业级应用标准，我呸，不就是一堆服务器以 http 提供服务吗，吹逼）。既然是企业级标准那自然得有自己的服务器标准。于是 Servlet 标准诞生，以此标准实现的服务器称为 Servle 容器服务器，Tomcat 就是其中代表，被 Sun 捐献给了 Apache 基金会，那个时候的 Web 服务器还是个高大上的概念，当时的 Java Web 程序的标准就是 War 包(其实就是个 Zip 包)，这就是 War 包的由来。后来随着服务器领域的屡次进化，人们发现我们为什么要这么笨重的 Web 服务器，还要实现一大堆 Servlet 之外的管理功能，简化一下抽出核心概念 servlet 不是更好吗，最早这么干的似乎是 Jetty，出现了可以内嵌的 Servelet 服务器。去掉了一大堆非核心功能。后来 tomcat 也跟进了，再后来，本来很笨重的传统 JavaEE 服务器 Jboss 也搞了个 undertow 来凑热闹。正好这个时候微服务的概念兴起，“ use Jar，not War ”。要求淘汰传统 Servlet 服务器的呼声就起来了

@catinred 其实你说的也不对，你一样可以 java -jar war 的方式跑起来，你可以去看看 jenkins。人家就是这么玩的

@svt jetty，Jboss，。建议你去理解一下 servlet 容器服务器的概念，只要实现了 servlet 容器的服务器都能跑基于 servlet 的 java web 程序

多数据源时的事务一致性属于跨库事务，跨库事务非常麻烦而且绝对不是你描述的这种结构能摆平的，一般的注解式事务只能针对单库，所以你用法就是错的，如果你再 service 层用了 @Transactional，那你就要保证这个 service 里调用的 mapper 都是一个库的，否则的话，就不要在 service 上用 @Transactional