江苏龙网

  1. 首页 > 人文 > >

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


而且代码会有**“破窗效应”**（这里其实不仅仅是单体架构 ， 对于所有架构来说都是如此 ， 只是单体应用更大的庞大 ， 业务界限不清晰 ， 因此这种问题更容易被放大） 。
有些人看到这就可能会说 ， 这上面还说开发方便 ， 这就又效率低下了？是的 ， 过犹不及 。
再比如一个新需求上线例如短信相关的 ， 并且订单也做了一些改造 ， 但是短信功能出了 bug ， 需要回滚的是整个应用 ， 订单模块冤啊 ， 陪着一起回滚 。
我在老东家做电商活动 ， 我们上线一个需求可能涉及6、7个服务 ， 回滚也得全部回滚 ， 而且都是负载均衡的 ， 那机器可能就是上百台了 。
语言单一 ， 不能根据场景选择更加合适的语言 ， 例如要实现数据分析 ， 应用的语言是 Java ， 那么就不能利用到 Python 丰富的类库 。
系统的整体可靠性不高 ， 什么意思呢？还是拿短信功能说事 ， 新上的短信功能写的有 bug ， 不管是堆栈溢出还是死循环等等 ， 核心的订单等功能都会受到影响 。因此你上线的功能有问题影响的不仅仅是这个功能模块 ， 可能是整体系统的瘫痪 。
像梦一样奔驰|毕业就在小公司躺了3年，再想找个老实的大厂待着，发现没人要…系统不易于扩展部署 ， 假设你发现你们的商品查询的流量特别大 ， 顶不住就得加机器 。 因为是单体应用所以为了商品查询这一个功能 ， 你需要在新加的机器上部署这一个应用 ， 没法单独为这一个功能做定制化部署 ， 对硬件资源有一定的浪费 。
总结的说缺点就是随着需求不断增长 ， 代码结构日益复杂 ， 各功能掺杂在一起 ， 系统耦合性高 ， 模块之间边界维护非常依赖开发者的个人水平 。
模块之间经常会有公共功能难以划分清楚 ， 添加或修改功能困难 ， 不确定是否会影响到其他模块 ， 所有功能都在一个进程内 ， 某个功能出问题可能影响的就是整个应用 ， 而且无法根据特点场景选择更加合适的语言去实现功能 ， 技术单一 。
随着用户的增长 ， 无法做到热点功能单独扩展 ， 只能整体应用部署 。
至此我们已经明白了单体应用架构的优缺点 ， 可以看出初始阶段单体应用优点突出 ， 随着需求和用户的增长渐渐的单体应用顶不住 ， 缺点在不断的放大 。
也就是说你的产品需要发展到一定的阶段 ， 单体应用才会顶不住 。 在这之前单体应用是你的最佳选择 。
你要是说我的产品肯定顶的 ， 所以一开始就大刀阔斧的设计 ， 单体应用太 low 坚决不用 。
可以的 ， 秀出你的花样 ， 你有你的 Young 。
像梦一样奔驰|毕业就在小公司躺了3年，再想找个老实的大厂待着，发现没人要…我们再来看下单体应用一般的架构图 ， 注意单体应用不是真的就线上部署一个 ， 好歹得两台 ， 互相 backup 下 ， 不能太虎一台顶 。
像梦一样奔驰|毕业就在小公司躺了3年，再想找个老实的大厂待着，发现没人要…又过了一段时间 ， 你发现你们还需要开发手机版 。 于是你们的架构又变成下图所示的样子 。
像梦一样奔驰|毕业就在小公司躺了3年，再想找个老实的大厂待着，发现没人要…没错 ， 为了让每个端不会相互影响 ， 粗暴的拷贝现有的应用 ， 稍加修改即可为手机版和小程序提供服务 ， 你会发现很多功能代码都是重复的 。 这时候来个需求你改的就是多份代码了 。
微服务架构又过了段时间你已经强烈感受到单体应用所带来的痛点 ， 这证明你的产品发展的不错 ， 一开始肯定会忍 ， 继续忍 ， 终有一天你会一拍桌子！来开个会咱们得还债了 。


推荐阅读


上一篇：人民网-财经频道|强产业补链条 全国海关助力打赢脱贫攻坚战

下一篇：台海网|高雄蓝营败选抓战犯？韩流五虎将杏仁哥点名：“他”该负全责