微服务，真的香吗？

如果你想从这篇博文里边学到什么装逼的本领，或者敲开某厂的大门，请出门左转。因为我的目的不是服务大众，而是纯粹吐槽。

不是为了更好的创造用户价值，而是为了微服务而微服务，是耍流氓的第一特征。-- 布鲁斯贾

有的团队做微服务是为了PPT上有更多东西可以写，一个本来规模很小复杂度也不高的东东，偏偏要搞成好几个service, 加上分布式缓存，再加点分布式锁，再考虑热备啊同步啊，妈呀，架构搞那么复杂了，付钱的客户还是只有一小撮。侬不晓得简单就是美吗？

代码容易腐败，而使用微服务架构更容易烂掉。-- 布鲁斯贾

开发人员实现一个新功能或者修一个新的bug的时候，往往要修改多个service。这意味着跨越多个repo工作, 更烦躁，更容易将代码弄乱 - 要理解多个service更难，理解多个部分的设计初衷更加有挑战性。

使用微服务之后，对于developer或ops engineers (或devops)而言，工作量常常变得更多了。别问我怎么知道的，反正自从采用微服务之后，我们这个小组，都是部门最晚下班的。

有人说微服务在技术方面的一个好处是，对于单一的一个服务来说，团队可以使用完全不同的编程语言和技术栈来做实现。这句话我初次听到，觉得好有道理。后来发现，也不是完全正确的。至少我所在团队一点都没有得到这个好处，因为在进度压力之下，肯定是选择自己团队最熟练的组合。程序员最大的天敌不是头秃，也不是颈椎病，而是有限的时间。所以我所看到的真实情况是：脚手架代码在好几个service里边重复，基本上都是copy-paste然后稍微修改一下。你可能要问“为什么不复用”，呵呵，当然可以，大家都知道复用是个传家宝，但是不容易用好。复用，是建立在合适的抽象层次上的，这个复用的部分在项目技术方案还没有那么稳定的时候一定会反复修改锤炼才能做到各个microservice都用得好，大家都开心。大家都不希望写烂代码，有些烂代码纯粹是项目进度压力逼出来的。

---

算了 v0.1就到这里，洗洗睡了。改天再来吐槽v0.2。