下面的文章是微博上某博主探讨微服务架构时的看法，大意是单体架构的边界比想象中宽广的多，和我的有些想法很契合，特转发至此。
Martin Fowler 开的公司是做技术咨询和外包服务的，最热衷这种新名词了 (不搞点新概念怎么开展新业务)。还有现在的云厂商也很乐于推微服务架构，多好的卖机器卖服务的机会啊，一个原本只用单机部署的系统鼓吹一下搞成微服务拆成 N 个系统后又可以多赚几倍的钱了。
我在传统行业做了 10 几年的企业应用，从地市级到省级系统，只要是面向内部用户的，就没有一个是单体系统满足不了的。微服务架构更适合那种用户规模起来之后的互联网企业，从阿里辞职出来之后，过去 8 年，我再也没参与过基于微服务架构的系统了，因为没有真实的需求。
我当初就是在阿里的中间件团队工作，微服务架构的系统所需要的三架马车全在我们组，包括服务框架、分库分表中间件、消息中间件。这三架马车我就参与了其中两架: 服务框架、分库分表中间件。
服务框架当初阿里的叫 HSF，除了最基本的 RPC 功能也有软负载，然后还得有 config server 做服务的注册与发现，搞到后面你还得做一个分布式调用链跟踪系统，为了存储分析调用链中的日志又得引入一整套的大数据领域的技术栈 (当年我们全网每天的调用量是 2000 亿起步)。
现在开源的微服务技术栈可以选用 Apache Dubbo 做 RPC 框架，但是服务注册与发现你还得配合其他的 (比如 Apache Dubbo 官方推荐用 zookeeper)。顺便说个八卦: Apache Dubbo 就是当年在阿里内部跟我们组的 HSF 竞争失败后开源出来的，现在能流行也是无心插柳。自从阿里云这家子公司做成了之后，发现微服务可能是门好生意，Dubbo 这个弃儿居然还有不少用户，然后又把 Dubbo 捡起来了，至于阿里云上面是套 Dubbo 的壳卖 HSF 的企业版还是别的动机我就不多猜了。
除了 Apache Dubbo，现在 java 平台上的微服务技术栈还有比较火的 Spring Cloud 全家桶，我只看过，但没有用过。vert.x 也有微服务的套件，我也没有用到真实的商业系统中。说白了就是没有几个系统需要上微服务。
以上说的还只是解决 API 层面的调用问题，你以为一个采用微服务架构的系统有了 Dubbo 和 Spring Cloud 就够了吗？错错错，session 管理在阿里都需要一个专门的小中间件，为了解决不同系统的消息传递问题，又得引入消息中间件。
还有最难的，数据层的问题怎么搞？你告诉我拆成了 N 个系统后还搞一个共享数据库？逗我玩呢。微服务架构的系统在数据库的层面基本上多是 OLTP 类型的，现在开源成熟的面向 OLTP 的分布式数据库可以说没有，别跟我提国内某司的 NewSQL 数据库，那东西在 OLTP 场景下的性能简直不能看，所以现在还是会用 MySQL 这样的传统关系数据库，然后搭配分库分表中间件来解决微服务架构系统的后端存储问题，拆分后的子系统都有自己的数据库集群。
我在阿里的 TDDL 小组做的 TDDL 就是用来解决 MySQL 的分库分表问题的，直到我辞职时的 2012 年都还不支持分布式事务，现在已经支持了。 TDDL 的性能是做到极致了的，是一种部署在在应用端的分库分表方案，在不涉及分布式事务的情况下基本上接近单机访问 MySQL 的性能。
说完了中间件后，最后再简单谈谈应用服务器，为什么谈这个？跟微服务有关吗？讲真，没有，但是谈到微服务的部署问题就头痛了。当年我在 HSF 小组时还负责应用服务器，有一次要推动 jboss 到 tomcat 的替换工作，因为阿里全网的系统就是拆拆拆之后的小系统组成的，我找了 100 多个系统来测试兼容性 (包括所有的核心系统，比如用户中心、商品中心、交易中心)，因为这些业务系统我都没有参与，所以我根本就没法把这些系统成功部署起来，连各个子系统的单元测试我都没跑通过几个。
所以，听我讲完了这些，你就明白一个单体系统被忽悠成一个微服务架构的系统后会有哪些坑了，要是还无脑往里跳，那就跳吧。
不到万不得已别搞微服务，别为了技术而技术，从码农自私的角度讲，当然希望把系统搞复杂，不难怎么体现自己的价值怎么多拿工资？但是从老板和甲方的角度想，那就是能简单就简单搞，能省钱就绝不乱花，警惕那些把项目当成技术试验田的人，这些人喜欢面向简历编程，哪怕项目失败了，也可以在简历上面大书特书用过微服务架构里的 “高级技术”，跳槽加薪不要太爽