Author: leelight

[转]流行20年的架构设计原则SOLID可能已经不适合微服务了 0

[转]流行20年的架构设计原则SOLID可能已经不适合微服务了

2000 年,Robert C. Martin 给架构师们总结出了一套原则来指导大家进行软件设计,Michael Feathers 随后按首字母将其总结成 SOLID 原则。从那时起,面向对象的 SOLID 设计原则就不断出现在相关书籍当中,并成为业界广为人知的指导方针:单一职责原则、开 / 闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。 Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle 在过去的这二十年里,软件开发领域一直在快速演进,特别是近几年云原生和微服务的发展,在微服务体系下,“SOLID 原则是否适合现代软件工程”引起了广泛讨论。

[汇总]数据分析经验 0

[汇总]数据分析经验

推荐2个十分好用的pandas数据探索分析神器! PandasGUI 在Jupyter当中使用的小插件名叫ipympl,能够使得matplotlib绘制出来的图表也能够具备交互性的特征,

[汇总] Spring 项目经验 0

[汇总] Spring 项目经验

1. Tech Spring Boot 最流行的 16 条实践解读! Spring Boot 项目打包 + Shell 脚本部署详细总结 Spring Boot 实现定时任务的动态增删启停 学会这10种定时任务,我有点飘了 Spring Boot 实现万能文件在线预览 Spring-Retry重试实现原理 重试框架用Guava-Retry,更便捷,更灵活! 那些让你爱不释手的 Spring 代码技巧 @Conditional @Import @ConfigurationProperties 我在 Spring 的 BeanUtils 踩到的那些坑,千万不要犯! Spring的BeanUtils的CopyProperties方法需要对应的属性有getter和setter方法;...

[转]一个复杂系统的拆分改造实践 0

[转]一个复杂系统的拆分改造实践

1. 1 为什么要拆分? 先看一段对话。 从上面对话可以看出拆分的理由: 1)  应用间耦合严重。系统内各个应用之间不通,同样一个功能在各个应用中都有实现,后果就是改一处功能,需要同时改系统中的所有应用。这种情况多存在于历史较长的系统,因各种原因,系统内的各个应用都形成了自己的业务小闭环; 2)  业务扩展性差。数据模型从设计之初就只支持某一类的业务,来了新类型的业务后又得重新写代码实现,结果就是项目延期,大大影响业务的接入速度; 3)  代码老旧,难以维护。各种随意的if else、写死逻辑散落在应用的各个角落,处处是坑,开发维护起来战战兢兢; 4)  系统扩展性差。系统支撑现有业务已是颤颤巍巍,不论是应用还是DB都已经无法承受业务快速发展带来的压力; 5)  新坑越挖越多,恶性循环。不改变的话,最终的结果就是把系统做死了。

[转]聊聊遗留系统改造的“道”与“术” 0

[转]聊聊遗留系统改造的“道”与“术”

让我们面对现实吧,我们今天所做的一切就是在编写明天的遗留系统。—— Martin Fowler 什么是遗留系统(Legacy System)?根据维基百科的定义,遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序,“属于或与以前的、过时的计算机系统有关” ,但仍在使用中。通常,将系统称为“遗留系统”意味着它可能已经过时或需要更换。 遗留系统改造是程序员的宿命,因为软件永远没有完成的时候。公司的业务始终在变化,软件架构和代码也只能随之不断变化,在数字化时代,这种变化更快了。

[转]一文带你彻底了解Java异步 0

[转]一文带你彻底了解Java异步

本文从以下几个方面结合真实项目异步改造经验对异步编程进行分析,希望能给大家一些客观的了解: 使用RxJava异步改造后的效果 什么是异步编程?异步实现原理 异步技术选型参考 异步化真正的好处是什么? 异步化落地的难点及解决方案 扩展:异步其他解决方案-协程   一文带你彻底了解Java异步

[总结]Postgre经验 0

[总结]Postgre经验

程序员硬核“年终大扫除”,清理了数据库 70GB 空间 在没有删除单个索引或删除任何数据下,最终释放了超过 70GB 的未优化和未利用的空间,还意外释放 20GB 未使用索引空间。

[转]日订单量达到100万单后,我们做了订单中心重构 0

[转]日订单量达到100万单后,我们做了订单中心重构

1. 背景 几年前我曾经服务过的一家电商公司,随着业务增长我们每天的订单量很快从30万单增长到了100万单,订单总量也突破了一亿。当时用的Mysql数据库。根据监控,我们的每秒最高订单量已经达到了2000笔(不包括秒杀,秒杀TPS已经上万了。秒杀我们有一套专门的解决方案,详见《秒杀系统设计~亿级用户》)。不过,直到此时,订单系统还是单库单表,幸好当时数据库服务器配置不错,我们的系统才能撑住这么大的压力。 业务量还在快速增长,再不重构系统早晚出大事,我们花了一天时间快速制定了重构方案。 重构?说这么高大上,不就是分库分表吗?的确,就是分库分表。不过除了分库分表,还包括管理端的解决方案,比如运营,客服和商务需要从多维度查询订单数据,分库分表后,怎么满足大家的需求?分库分表后,上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定,还需要考虑相应的降级方案。

[总结]MySQL经验 0

[总结]MySQL经验

SQL连接图解演示-共七页   数据库底层数据结构与数据库索引类型 跳表,哈希索引,SSTable,LSM树,B树,倒排索引,R树,后缀树。   如果MySQL磁盘满了,会发生什么?还真被我遇到了! 要进行磁盘碎片化整理。原因是datafree占据的空间太多,看看自己的系统的datafree大不大 show table status from 表名; 100G内存下,MySQL查询200G大表会OOM么?   MySQL中ORDER BY与LIMIT 不要一起用,有大坑 如果order by的列有相同的值时,mysql会随机选取这些行,为了保证每次都返回的顺序一致可以额外增加一个排序字段(比如:id),用两个字段来尽可能减少重复的概率。