这几年，胖哥经历了好几家创业公司。不乏使用微服务的初始试验和错误。我想很多人都有和我一样的疑问，微服务真的能解决创业公司面临的问题吗？作为一名软件工程师，我非常喜欢微服务的概念。甚至在2017年尝试过SpringCloud写脚手架。我曾将微服务视为一颗“灵丹妙药”，可以帮助企业走上正轨。现实打了我一巴掌，用户量不到50万，最高DAU超过1000，交易量屈指可数，连市场的监控都没有出现过流量高峰和阈值警报。但是每天都要和网络、集群打交道，完全不符合公司的业务量。我什至见过10多个微服务模块拆分却共享一台服务器，空载已经达到硬件门槛；我还看到了在数据库模式上运行的微服务的风格；听说公司只有一个开发但是支持微服务架构。虽然这在技术上是允许的，但实际上这不仅违背了微服务的设计理念，而且拖累了整个项目。我们读到的关于微服务的文章大多都在谈论解耦、去除开发团队之间的依赖、更好的横向扩展等，却忽略了划分业务边界的难度和设计、开发和部署微服务的复杂性。从可靠性的角度来看，当我们使用微服务时，不同服务之间的通信失败的概率更高。另一个痛点是运行微服务的成本，可能需要更多的硬件资源，小公司和创业公司往往不愿意投入，需要更多优秀的工程师，而创业公司往往不能投入太多的人力。同时，各种服务的编排和监控也对运维能力提出了更高的要求。那么我们什么时候应该转向微服务呢？我个人认为，当单体项目足够复杂，公司运营数据逐渐好转时，就可以开始准备切入微服务了。在早期，微服务只会增加我们的负担。那些成功的独角兽，包括国外最好的微服务实践者Netflix、Airbnb，都是从单一架构起家的。当他们的业务发展到良性阶段时，他们转向了微服务。如果一家初创公司还在反复试验，我仍然建议使用单体架构，除非你对公司有仇。本文转载自微信公众号“码农小胖哥”，可通过以下二维码关注。转载本文请联系码农小胖公众号。
