像梦一样奔驰|毕业就在小公司躺了3年,再想找个老实的大厂待着,发现没人要…

点赞再看 , 养成习惯
前言之前写了一篇秒杀系统的文章 , 最后给自己埋了分布式事务的坑 , 然后很多读者就要求我去写分布式事务 , 那作为程序员届的暖男 , 我一向是有求必应的 , 就算是不睡觉我都要写给你们看的!
像梦一样奔驰|毕业就在小公司躺了3年,再想找个老实的大厂待着,发现没人要…因为分布式事务是:分布式 + 事务 = 分布式事务 。
理所当然的要先谈谈分布式 , 而分布式又得谈谈这个概念是如何演进得来的 , 因此作为创作鬼才的我 , 就先来讲讲架构的演进 , 什么叫分布式?什么是集群?SOA、微服务这两个东西的关系和区别 , 下篇再讲分布式事务 。
因为我发现我读者大多都是学生或者跟我一样刚毕业不久 , 那一直听分布式估计都听腻了 , 估计都还不知道分布式的一些细节和架构演进路线吧 。
像梦一样奔驰|毕业就在小公司躺了3年,再想找个老实的大厂待着,发现没人要…先来说个题外话 , 我一直追崇一个技术点不仅要理解其原理 , 还需要知道这个技术点解决了哪些痛点 , 这些痛点又是由什么引发的?这个技术还未诞生的时候是如何解决的?
也就是整体的演进过程 , 历史脉络 。
比如为何需要HTTP?HTTP0.9为何需要演进到HTTP1.0? 进而又向1.1、2演进到最新要将Google开发的基于UDP的QUIC协议应用到HTTP3中 。
搞懂这些来龙去脉相信你不仅仅对HTTP会有更深层次的理解 , 对网络也会有更加深刻的认识 。 当然也不是说一样东西一来就得全盘理清 , 有些东西还是比较复杂的 , 只是说我们要往这个方向去学 。
这也是我一直觉得很重要的一个学习思想 , 知其然知其所以然 , 会让大家更好的理解很多东西 。
一般架构的演进过程好了 , 让我们回到今天的主题 , 咱们先来看看一般架构的演进过程 。
为什么说一般呢?举个例子 , 比如某线下龙头企业 , 现在想开展网上相关业务 , 那么有大批线下忠实用户的支撑 , 并且自身钱包鼓鼓 , 人力财力都不缺 。
那么线上的软件架构就得考虑清楚了 , 几乎不可能按照初始阶段来 , 当然也不能用力过猛 , 实际得靠架构师以及团队实力进行权衡 。
像梦一样奔驰|毕业就在小公司躺了3年,再想找个老实的大厂待着,发现没人要…单体应用架构什么是单体应用?简单的说就是不管啥功能都往一个应用里写 , 比如电商系统 。 用户功能、商品功能、订单功能等等 , 都往一个应用里写 。
这有什么好处?在项目初期 , 小公司人力财力不足 , 急于拓宽市场 , 这种单体应用架构简单粗暴 , 将所有的功能都打包在一个的应用中 , 直接部署 。
本地开发调试方便 , 直接起一个项目 , 调试也是在一个进程内 , 没有冗长跨进程的调用链 , 出错可快速定位 。
本地的函数调用 , 没有网络调用的开销 。
线上出了问题回滚这一个应用即可(这一点其实在某种程度上看是优点 , 某种程度上看是缺点) 。
总结的说就是开发、测试、部署方便 , 本地调用对于远程调用性能较好 。
像梦一样奔驰|毕业就在小公司躺了3年,再想找个老实的大厂待着,发现没人要…有什么坏处?系统耦合性高 , 导致开发效率低下 。
一开始可能模块结构还很清晰 , 随着需求日益增长 , 不断的添加新功能 , 代码量巨增 , 模块之间的边界开始模糊 , 调用关系开始混乱 , 整体的代码质量非常依赖个人水平 。
假使某个同事水平较差 , 实现的代码冗余 , 逻辑混乱 , 这时候要在上面添加新功能或者修改老功能其实是一件很困难的事情 , 你不能保证你修改的功能模块不会影响到其他功能 。


推荐阅读