七夕情人节之架构重构

el/2024/6/13 22:36:13

序言

    掐指一算,十年不遇的七夕情人节快到了,你准备好了吗。。。

    看我不爽可以,但是你要打得过我朋友,他发起神经就不是打我这么简单的了,他狠起来连自己都打。

风言风语

    1 架构重构

    系统太慢,找出慢sql优化试试,开发效率低,把系统给拆分拆分,一个系统,如果故障频发,找不到故障点,那么怎么优化,如果找不到系统的瓶颈,那么怎么优化呢?

    接手一个烂系统,emmm。。。为了维护有些人的面子,不能说烂,要说还有很大的改进空间,所以呢,就可以进行架构重构了。。。

    架构重构的首要条件就是,如果是从0到1设计这个系统,那么和现在的系统有什么区别?能解决哪些已知问题?对于这些已知的问题,能达成多少倍的改进。。。这需要很多的前置工作,分析现在的系统架构,找出目前存在的问题列表。。。

    细细说来,架构重构和离婚好像很像的感觉,在架构重构的时候,需要考虑两件事情,一个是应用层架构的重构,可以进行拆分,降低系统之间的依赖,就像离婚,哎哟,两个人分开了,不是不爱,是实在是不能忍受目前的一些问题,看看应用重构,也是一样的道理,你无法忍受相互模块或者功能的依赖,一个出问题,整个系统都受连累,就像离婚吵架,一吵架,都不好过。。。没有依赖,就没有伤害。。。

    另外一件事就是持久层的重构,就像离婚时候的财产分割,这个我买的,那个也是,这个就像数据库的重构是一样的,这个表里面有部分数据是业务系统的,还有部分数据是管理系统的,什么都混杂在一起。。。离婚呢,受苦受累的都是孩子,就像持久层的各种非结构化数据,例如文件存储呀,键值存储呀。。。分割起来还是比较麻烦的。。。持久层的重构要么需要进行数据割接,要么还把孩子作为共有的一部分,这部分就不拆了,毕竟存储的拆还是非常麻烦的。。。

    我们总说要重构,但是在各种爆发的问题背后,最核心的问题是什么,我们要解决的问题是什么?就像离婚的时候,离婚解决了什么?换一个对象就不会发生同样的问题吗?重构还好一点,毕竟是针对性的进行求解,而且时间是可以估算的。。。但是,离婚后的再婚就不好说了,毕竟很难说是某个人导致的问题。。。很多人说,一个巴掌拍不响,但是我从来都不信。。。你把脸伸过来,我一个巴掌你看看香不香。。。

    想进行架构重构的时候,想清楚一个问题,风险,这个表示业务已经上线,如何让产品,技术去承担更换系统的风险;价值,这个表示如何说服老板投入资源去做这件事情;计划,这个表示有明确的时间点可以达成目标;投入成本,所花费的时间,消耗的人力。。。最终的收益就是价值减去成本。。。可衡量的指标,可度量的目标。。。

    2 烂架构的由来

    其实也不能说是烂架构,不能指责,不能抱怨,不能埋怨,要说,这个架构不太适合目前业务的发展,当初设计的时候,受限于人力,时间,从而导致架构没有进行恰当的设计,迫于业务的紧促性,从而导致了今天。。。

    就像结婚,并不是说因为爱情,而是迫于环境的压力,迫于年龄的压力,迫于同龄人的压力,导致不得乖乖去做这件事。。。爱情?想的美。。。哈哈哈

    在合适的年龄碰上了合适的你。。。这才是好的架构,能共同的成长,能有所包容,能有所不同,那么问题来了。。。你是选择你爱的,还是选择爱你的。。。

    一般呢,你选择你爱的,那么就会出现一种情况,这种架构能力你无法掌控,或许是技术不够,或许是能力不足,从而会导致出现各种各样的故障,看似主动,实际被动。。。

    其实,架构出现问题,也是一件好事,说明业务在快速发展,而架构如果一直不出现问题,那说明业务也就那样了,没准哪天就做黄了。。。所以呢,机遇与挑战并存。。。

    我们活在今天,却在计划明天。。。那么问题来了,你到底图啥。。。

    爱一个人很难,就像牛郎织女。。。一年才见一次,所以呢,很多东西,不是努力就够了,不要问原因。。。问就是因为爱情。。。天下没有无缘无故的爱,也没有无缘无故的恨。。。不要问,问就是因为爱情。。。哈哈哈

    说好的情人节,说啥离。。哪壶不开提哪壶,不是故意的,而是有意的。。。怪我咯。。

    最近看了一本书,叫架构即未来。。。看着看着,怎么感觉。。。跪着即未来。。。你品,你细品。。。

    不要问我脑子天天在想啥。。。我根本就没有脑子,哈哈哈。。。先买后开输赢天定死而无怨。。。既然是咸鱼,就不要给自己加戏,毕竟。。。咸鱼翻身还是咸鱼。。。


http://www.ngui.cc/el/5239895.html

相关文章

越优秀的人越努力

序言 作为一个过来人,经历了很多事,看过很多人,给你们年轻人一个忠告吧。。。别过来。。。 不经一事,不会成长,这句话的成立是有条件的,就是你能反思到这件事你错在哪儿,而大部分事情&#xff0…

解决方案之合作

序言 问别人问题,答非所问,已是答案,无需再问。。。问也是自讨没趣。不响应是一种答案,转移话题也是一种答案,直接回复也是一种答案。 互利共赢,这是一个合作的前提,碰到很多人,你会…

闲聊晋升

序言 又到四季之末,有的人喜,有的人愁,有的是晋升,有的人是净身。 都是公司恩怨,不要不专业。。。在很多的地方需要抹灭人性的光辉,毕竟。。。一群无情无义的人为了数字游戏聚集到了一起。 风言风语 1 与众…

2020之年终决算

序言 今天是2020年的最后一天了,其实大部分人基本上没啥感觉,毕竟现在过年过节也不是一个稀罕物了,不过,年终决算不会迟到也不会早退,就在今天。 年终决算是指对今年的业务情况和财务收支情况进行综合结算的工作。 风言…

hadoop之yarn调度

序言 在大数据的生态中,hdfs解决了海量数据的存储问题,mapreduce解决了海量数据的计算问题,而在任务的执行和资源统一管理层面,则是使用yarn进行统一调度。 yarn:yet another resouce negotiator,另外一种资源调度器。 yarn 1 为什么会有yarn hadoop经历…

hive初始化元数据库乱码

序言 无论是使用何种语言进行编程,碰到的第一个问题莫过于乱码的问题,而使用数据库的时候,也大致差不多。 hive使用元数据库来记录相关hdfs数据文件和数据库表之间的映射关系,当创建的数据库是使用中文注释的时候,那么就会碰到乱码问题。 HIVE元数据库乱码 1 …

hive之编译源码

序言 使用maven来进行源码,真的是靠运气,特别是你网络很差的情况下,再特别是你没有本地库的时候,靠运气吃饭。。。 本来不想编译的,奈何在hive中执行show create table table_name的时候显示为乱码。。。当一切都很顺利…

hadoop生态之sqoop

序言 在使用大数据的时候,各种不同的数据都要将数据采集同步到数据仓库中,一个是属于业务系统的RDBMS系统,也就是各种关系型数据库,一个是hadoop生态的存储,中间用于传输的数据的工具可以使用sqoop,也就是sql to hadoop。 在数据进入数仓的ODS层的时候,使用sqoo…

hdfs和yarn高可用对比

序言 总有一天你会笑着说出曾经令你痛苦的事情,毕竟有些东西虽然不是你想要的,但是却是你自找的,表面上是无奈,实际上是懒得去做选择,成功的路只有一条,而失败的路则是各种各样的原因。 得不到的时候念念不忘,得到的时候,却不珍惜,这到底是为什么呢?是忘记了…

三月闲聊

序言 生活原本很沉闷,但跑起来有风。 工欲善其事必先利其器,当你有一些想法的时候,如果没有合适的工具,那将是一个很痛苦的过程。。。至于有多痛苦呢,越追求细节的越enjoy。。。 风言风语 1 在理论的指导下实践 无论是…