转一个今天看到的：

又看到好几个网友让我扯扯微服务架构，在前面谈到后端技术体系的微博时，有说到中间件那一层的技术就是现在所谓的微服务架构中涉及的中间件，就是不想提微服务这个词而已，这条长微博就专门说微服务。

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 多个系统来测试兼容性 (包括所有的核心系统，比如用户中心、商品中心、交易中心)，因为这些业务系统我都没有参与，所以我根本就没法把这些系统成功部署起来，连各个子系统的单元测试我都没跑通过几个。

所以，听我讲完了这些，你就明白一个单体系统被忽悠成一个微服务架构的系统后会有哪些坑了，要是还无脑往里跳，那就跳吧。

不到万不得已别搞微服务，别为了技术而技术，从码农自私的角度讲，当然希望把系统搞复杂，不难怎么体现自己的价值怎么多拿工资？但是从老板和甲方的角度想，那就是能简单就简单搞，能省钱就绝不乱花，警惕那些把项目当成技术试验田的人，这些人喜欢面向简历编程，哪怕项目失败了，也可以在简历上面大书特书用过微服务架构里的“高级技术”，跳槽加薪不要太爽

是不是跟公司规模也有点关系？有些大厂搞微服务那些主要是想做“分工”，觉得每一块都负责自己专职的部分。到时候维护也会有专门的人员来搞。跟前后端完全分离的借口是差不多的。DHH 的公司也就 45 十号人，有空都早点下班回家陪孩子好啦，多出来的钱还不如发给员工当福利 既然“城堡”模式够用何苦瞎搞。

我来胡说八道几句。

DHH 的问题在于没有到有复杂业务、流量洪峰的公司做事情，所以拿着单体架构沾沾自喜。单体架构是一个极低成本，实现软件功能的途径，虽然大公司会搞很多微服务，但是像后台系统这种在大公司也是单体存在的，选择是基于场景的。这扯出了第二个问题，大部分在谈微服务的人都在出的问题。

没有基于实际需要、场景分析，就对微服务一顿狂喷，或者不限制地吹捧。

你看看发表评论的人是不是这样？一会儿分山头、势力范围、政治斗争、我觉得 XX 好，尽喷些滑稽的话，丝毫没有从业务、实际问题、解决方案、解决成本、实际场景去分析问题，然后基于问题对微服务、单体等架构模式发表观点。

举个例子，假设某人有一笔钱，问该怎么处理好呢？是放保险柜、交给老婆管、放银行、买股票基金、黄金、国债？选哪个好，有很多人就开始说了，国债稳定低风险、股票能赚钱、银行最保险还能取··· 就差有人问“你的钱金额多大，你对现金需求是怎样的，你对增值风险的期望是？···”

业界对微服务早就有极其明确的观点：不要轻易使用，但也是复杂场景下唯一的选择。

假设就做个后台系统，逻辑简单，QPS 不足一千，对稳定性要求不高。这在哪家大公司我像都更容易选择单体结构，但现实是，大公司微服务构建成本、基础设施极为健全，所以可能会往拆分上靠，但目标是怎么快怎么来。

但是你有月活 1 亿，甚至日活 1 亿呢？用单体架构就是找死，在研发效率、硬件成本、稳定性、鲁棒性、问题分析···等各个方面都是致命的问题。微服务架构是唯一的路，虽然成本高，但只要基础设施健全，好处是极为明显的。

很多人就喜欢盯着某的小业务需求，去分析思考用什么架构，一个小的或者独立的功能需求，不管怎么看，单体架构都和合适，也简单。但把眼光稍微抬高一点点看，假设公司有上百个这种业务呢？各个业务间都关联，有层次之分呢？有流量洪峰呢？怎么做让整体架构的熵最低，理解成本最低，互相调用成本最低，迁移成本最低等等 N 多种成本考量呢？

微服务架构是一种基于全局的考量，不是基于单个业务、单个功能的。也只是一种解决问题的途径和思维方式。

之前写从上帝视角看微服务时，就对很多评论感到心寒，悲剧的是，还有很多人点赞叫好，钻到小角落里不出来。

言辞有些激烈，但本意是希望社区能有更多角度、更有深度的思考，这样才能让 ruby-china 走向更好。