系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？（微服务初衷本是降低成本，但拆分和独立布署增加了复杂度和低效，需要理性分治和兼顾合成才能掌握微妙之处。中台病同样存在，业务驱动带来低效。阿里中台困难，但不代表别人不可能成功。）

微服务初衷本是降低成本，但拆分和独立布署增加了复杂度和低效，需要理性分治和兼顾合成才能掌握微妙之处。中台病同样存在，业务驱动带来低效。阿里中台困难，但不代表别人不可能成功。

微服务的初衷大概是因为服务化成本太高，想做低成本的服务化，乃名微服务。但病诊对了，药没开对，多数吃药的反而病情加重了，吃药后因为服务化带来的繁琐和低效更甚以前。总之，病是真病，药是错药。这一点和中台倒很像。

微服务的药方，大多是拆分邪路，restful邪路，独立布署邪路。这些都是增加成本，降低效率的。

以拆分为例批一下（这破概念毛病太多，懒得一一批了）

一个业务的复杂度不会因为拆分而减少。相反还会增加额外的技术成本，协作成本。整体复杂度是升高而不是降低的。开发效率是降低而不是升高的。

正确的做法是

1，了解拆分是业务复杂度到一定程度下，难以控制的分治之法。复杂性无法治理是前提。

简单业务用分布式微服务框架，无疑是火车拉芝麻。效率低下，成本高昂。

2，知道分治这种方法存在的问题，会增加合成成本。警惕拆分，理智分治。分治之法为不得已法。

正确的做法是一只眼看拆分，一只眼看合成。拆分以分治领域复杂度，合成兼顾学习，使用，运维低成本。

大多数人只看前者，忽视后者。这就导致大多数微服务的深入实践效果并不好。这根本上是由于微服务本身的哲学思想分治的必然结果，而大多数人难以体会掌控其中的微妙之处。很难使用的好。

但是类似springboot、springcloud等经过幸存者偏差而存在微服务框架的确是好的。

初学者使用微服务，原业务不动，基础设施换为微服务框架，最初一定会得益于大量基础设施，感觉东西好。

但是，如果不深入拥抱，只是浅尝辄止，只是将框架换为微服务，在微服务原教旨主义者看来不过是换了一件衣服。是假的微服务，是可鄙的，low的。而初学者也难以自视，多数会追求进步。而一旦深入，开始拆分业务。一定会越来越差。

这其中奥妙是第二只眼兼顾合成的要求实在是太高，兼顾合成本质是要预料未知（的业务情况）做应对，使得业务发生的时候极具针对性，使用简单底层本。这前提是大量知识和经验前提这本身已经足够pass掉大多数人了；并且内置业务变化适配也是违反内聚耦合的；其中设计还要掌握尺寸，既不过度设计，还要简单好用；玄之又玄，其难度远超普通开发甚至大多数所谓架构师的水平。很难掌控的住微妙。微服务确实是很好，却不具备方法的一般性。普通的公司、个人极少见到用的好的。

所以，大多数的微服务实践，一定是越深入越烂。所谓拆分一时爽，合并火葬场。霸王枪不是人人都hold的住的。

中台的病，不是服务低效病，而是中国式的业务驱动式开发带来的低效病，最终产生了焦油坑。本质是《人月神话》所描述的软件工程面临的深层次的痼疾。虽然是马云第一个看病，但是效者云集，一时洛阳医贵，人人皆以病为荣，以中台为荣。

虽然不少楚王细腰，但其实也是星星之火，非一日之寒。万企热热闹闹做中台，大部分还都是有病的。人月神话的病，焦油坑的病，谁没有呢？病必定在，不过轻重缓急而已。只要软件在变，业务在变，就有病。不过是变得频率快慢，决定了病的急徐。这是软件内在的规律决定的。

中台病虽然开了一堆的药方，但仔细看看，却发现什么字都没有。另外很多数据中台，技术中台，XX中台，看起来不像药方，倒像蹭饭。

要说和微服务的不同，可能是药方都没开的出来，各种江湖偏方、野郎中纷纷上阵，万众中台，人人试药。不过至今没见到有效果的。不过吃挂了的倒不多见。这倒是不开药方的好处了，好歹乱吃的时候，还是有点辨别的；若大师开了药方，便是虽然直觉不妙，但是捏着鼻子也要硬吃下去的。

中台病难治啊。 阿里最初定了个15一18的三年中台战略，不过一直到19年都没宣布成功。19年行癫宣布阿里不做saas只做被集成。这意味着阿里在业务市场上的疯狂扩张进入了停滞期，业务中台战略碰到了极大困难。19年末业务中台大将玄难离职。星环陨落。

但，阿里中台不成功，未必别人不成功。没有证据证明阿里现在的技术就是最完美无瑕的，不能再做进化的。也没有证据证明中台阿里做不成别人必然做不成。但可以知道的是我们现在的技术和现况距离完美无瑕还差的很远。并且人月深化虽然号称没有银弹，却也没有确切的逻辑和证据能证明这一点。

微服务化的系统架构：优点与缺点

简介

系统架构中，微服务是很流行的，尤其是现在我们的系统的数据越来越大，越来越复杂，为了设计更合理，支持高可用、高性能，最好的实践方式就是进行微服务化。其中的优点就不多说了。单就从缺点层面来分析。

对于开发人员的技术要求越来越高，随着服务的微服务化。一个系统的微服务应该怎么拆，拆的维度是什么？这个是没有一定的标准可言，而是要根据项目本身的业务而定，这就需要一个有经验的架构师进行微服务化。而是简单的进行垂直拆分即可。

除此之外你还需要考虑如何避免多个微服务之间开发人员的重复开发工作，做到公共资源的合理分配。微服务中的监控指标数据等。

这样的拆分对于之后的系统升级、扩展是不是合理，会不会导致系统架构重组等问题，都是其中的一个弊端。

随着你的微服务化，会导致服务数量的激增，你需要去维护更多的服务，以及服务之间的性能监控，数据调用链等数据指标。而传统的单体方式，本身的调用都是内部的，你只需要维护单个应用即可。

注意，这个也并非是指分布式，而是你的系统微服务化，所以传统单体应用也可以做到高可用。

微服务之间的调用方式是通过RPC方式来进行数据交互，相比传统模式，你需要考虑过载、消息丢失、重试、负载等场景，需要处理的逻辑也很多。

首先你需要有一个注册中心，来帮助微服务之间的调用，这是一个需要额外实现的点。

另外在服务调用（服务发现）的时候，会存在负载均衡、容错、代理透明、RPC协议中的序列化、协议编解码等比较复杂的详细逻辑，都是需要微服务化需要去考虑的。

分布式锁、分布式事务层面的问题，你都需要再进行设计，在传统的模式下，这些都是在同一个应用里面进行，不存在问题。但是微服务化后，你为了保证数据一致性，这些相关的点，都是你需要进行额外的开发。难度成本也会成倍加高。

随着你需要为了微服务化，而加入更多的解决方案的时候，你的系统会变得更加的复杂，虽然架构清晰，设计合理。但是其中的性能问题，也是你不得不考虑的问题，越多的中间件组合在一起，只要其中一个环节出现问题。你整体的性能就会大打折扣，比如你微服务RPC环节、通信延迟、微服务宕机等情况。不像传统模式，环节少。

微服务化的优点很多，但是同时带来的问题也是客观存在的开发要求高、复杂性、性能等。

针对以上的一些拙见，个人的建议是对于你是否引入微服务化，应当考虑维度在于业务逻辑和系统边界是否清晰。可以先从最简单的传统单机模式开发，渐渐稳定系统后可以再慢慢的微服务化的拆分工作。