原创

【思考】小项目的误区就是用了微服务架构

前言

微服务很好,非常好,及其好,特别好,当一个技术leader带领几个不同的团队做一个超级大的项目的时候,可以使用微服务的架构来进行架构的设计,这个大家都懂。

但是如果是小项目呢?一个简单的官网,一个官网中的文章发布系统,如果用微服务来设计,那将会是错误的,小项目,还是用单体应用方式吧,SA还是很香的。

不过也可以理解,很多开发者,都是学的微服务,都为了未来而战。

这就引申出一个问题了,公司项目大小的问题,大公司,有钱有人,那微服务搞吧,小公司,没钱没人,就不要想太多拉!

什么是微服务

微服务就是由一个一个小的服务,每个服务都有自己的进程(服务器、节点等),通过明确定义的API与其他的服务进行通信。

为什么微服务对小项目来说是一个错误

比如有一个SaaS产品,5个工程师,用微服务就会这么设计:
1.授权服务
2.用户服务
3.计费服务
4.付款服务
5.通知服务
每一个服务都有自己的项目,都能独立运行(非业务),有自己的数据库。
用户提交一个账户创建的申请,流程如下:
1.授权服务收到请求
2.在授权服务中判断要不要创建用户
3.用户服务收到请求
4.用户服务在数据库中创建用户
5.通知服务收到请求
6.发送欢迎的邮件
7.将欢迎邮件存储到数据库中。
实际上一个创建用户的服务,却要几个服务都打通才能运行,可想而知这个效率:
1.三个项目都需要调整
2.三个项目都需要测试&部署&上线
很多工作,但是都是狗屁工作,而且严重影响上线时间。

上线变慢

即使是一个简单的功能,也需要多个人进行开发(人/日)需要变更多个项目,需要测试多个项目,需要上线多个项目。

更容易出现bug

每个服务都需要有自己的数据库(缓存),要保持数据的一致性需要更多的花费,关系型数据库的事务一致性无法保证更用不了。
每个服务调整,系统之间更容易出现沟通成本,理解的不同就会导致差异,需要完善的文档支持。

替代方式

早期的小公司就不要用微服务了。

请继续使用单体应用开发方式!!!!

  • 所有的代码都在一个服务中,分服务使用依赖包的方式进行区分。
  • 单体不等于混杂或者融合,需要一个技术leader将界限区分开来。
  • 数据一致性
  • 运维高效简单,启动停止都更加快速
  • 有的技术大佬可以简单的拆分系统,直接到微服务架构中。

好处

  1. 产品快速迭代
  2. 构建更快速,上线更快速,花费人力更少
  3. 降低系统错误耦合
  4. 更少的测试周期
  5. 省钱,省人力

本文来自:【思考】小项目的误区就是用了微服务架构-小码农,转载请保留本条链接,感谢!

温馨提示:
本文最后更新于 2023年09月01日,已超过 294 天没有更新。若文章内的图片失效(无法正常加载),请留言反馈或直接联系我
正文到此结束
本文目录