【思考】小项目的误区就是用了微服务架构
前言
微服务很好，非常好，及其好，特别好，当一个技术leader带领几个不同的团队做一个超级大的项目的时候，可以使用微服务的架构来进行架构的设计，这个大家都懂。
但是如果是小项目呢？一个简单的官网，一个官网中的文章发布系统，如果用微服务来设计，那将会是错误的，小项目，还是用单体应用方式吧，SA还是很香的。
不过也可以理解，很多开发者，都是学的微服务，都为了未来而战。
这就引申出一个问题了，公司项目大小的问题，大公司，有钱有人，那微服务搞吧，小公司，没钱没人，就不要想太多拉！
什么是微服务
微服务就是由一个一个小的服务，每个服务都有自己的进程（服务器、节点等），通过明确定义的API与其他的服务进行通信。
为什么微服务对小项目来说是一个错误
比如有一个SaaS产品，5个工程师，用微服务就会这么设计：
1.授权服务
2.用户服务
3.计费服务
4.付款服务
5.通知服务
每一个服务都有自己的项目，都能独立运行（非业务），有自己的数据库。
用户提交一个账户创建的申请，流程如下：
1.授权服务收到请求
2.在授权服务中判断要不要创建用户
3.用户服务收到请求
4.用户服务在数据库中创建用户
5.通知服务收到请求
6.发送欢迎的邮件
7.将欢迎邮件存储到数据库中。
实际上一个创建用户的服务，却要几个服务都打通才能运行，可想而知这个效率：
1.三个项目都需要调整
2.三个项目都需要测试&部署&上线
很多工作，但是都是狗屁工作，而且严重影响上线时间。
上线变慢
即使是一个简单的功能，也需要多个人进行开发（人/日）需要变更多个项目，需要测试多个项目，需要上线多个项目。
更容易出现bug
每个服务都需要有自己的数据库（缓存），要保持数据的一致性需要更多的花费，关系型数据库的事务一致性无法保证更用不了。
每个服务调整，系统之间更容易出现沟通成本，理解的不同就会导致差异，需要完善的文档支持。
替代方式
早期的小公司就不要用微服务了。
请继续使用单体应用开发方式！！！！
- 所有的代码都在一个服务中，分服务使用依赖包的方式进行区分。
- 单体不等于混杂或者融合，需要一个技术leader将界限区分开来。
- 数据一致性
- 运维高效简单，启动停止都更加快速
- 有的技术大佬可以简单的拆分系统，直接到微服务架构中。
好处
- 产品快速迭代
- 构建更快速，上线更快速，花费人力更少
- 降低系统错误耦合
- 更少的测试周期
- 省钱，省人力
本文来自：【思考】小项目的误区就是用了微服务架构-小码农，转载请保留本条链接，感谢！
- 本文标签： 微服务 单体服务
- 本文链接： https://djc8.cn/archives/thinking-the-misunderstanding-of-small-projects-is-the-use-of-microservice-architecture.html
- 版权声明： 本文由小码农原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
热门推荐
关于我
近期评论
-
来自： [typecho]做了一个书架插件
-
来自： [typecho]做了一个书架插件
-
来自： [typecho]做了一个书架插件
-
来自： [typecho]做了一个书架插件
-
来自： 【Android】KOReader墨水屏用阅读器
