过去几年，胖哥经历过几个初创的公司。其中不乏使用微服务进行初期的试错。我想很多人也跟我一样会有疑问微服务真的能够解决初创公司面临的问题吗?
作为一名软件工程师，我非常喜欢微服务的理念。甚至在17年就尝试了Spring Cloud来编写脚手架。
我一度认为微服务是一种“灵丹妙药”，可以帮助公司走上正轨。现实打了我一巴掌，不到五十万的用户量，日活最高过千，屈指可数的成交量，甚至监控大盘从来没都没看见过流量洪峰和阈值警报。而每天却要和网络、集群打交道，完全和公司业务体量不搭界。
甚至我见过拆分了10多个微服务模块却共用着一个台服务器，空载就已经达到了硬件的阈值;我还见过微服务有模有样地跑在一个数据库Schema上;甚至还听说过公司只有一个开发却支撑了一个微服务架构。虽然从技术角度允许这样做，但事实上这不仅违背了微服务的设计理念而且拖累了整个项目。
我们阅读到的大多数微服务相关的文章都在谈论解耦、消除开发团队之间的依赖关系、更好的水平可扩展性等等。却忽视了业务边界划分的难度以及设计、开发、部署微服务的复杂性。从可靠性的角度来看，当我们使用微服务时，不同服务之间的通信过程中出现故障的可能性更高。另一个痛点是运行微服务的成本，可能需要更多的硬件资源，而这往往是小公司、初创公司不太愿意投入的。还需要更多优秀的工程师，而初创公司往往无法投入过多的人力。同时各个服务的编排和监控同样对运维能力提出了更高的要求。
那么何时应该转向微服务?我个人认为，当单体项目已经足够复杂，而且公司的运营数据逐渐有了起色就可以着手准备切入到微服务。在早期阶段，微服务只会增加我们的负担。
那些成功的独角兽，包括国外微服务践行的最好的Netflix、Airbnb都是从单体架构开始的，他们业务增长到了一个良性的阶段，他们就转向了微服务。如果一个初创公司还在试错，我还是建议使用单体架构，除非你跟这家公司有仇。
本文转载自微信公众号「码农小胖哥」，可以通过以下二维码关注。转载本文请联系码农小胖哥公众号。
