yang1fei2的博客

在搭建简单的Qt Demo的时候，我们可以将所有的代码写在一个工程里面，这样操作起来比较简单。但是，如果在一个有很多个开发者参与的大型项目中，这样做肯定就不行了，这时候我们需要对项目进行拆分，拆分成几个可以独立并行开发的工程模块。这里介绍的就是如何对项目进行拆分。首先采用简单的MVC结构对项目进行拆分，将UI显示和业务逻辑拆分开发，这样设计工程师就可以专注于UI的设计，同时开发工程师专注于业务逻辑的开发。前端设计不用关注实际的业务逻辑，而业务开发工程也不用关注前端的UI显示。拆分开之后，桌面端和移动端的

在互联网应用中，当出现线上问题的时候，由于应用涉及到的功能模块非常多，在排查和定位问题的时候非常艰难。这也就导致了在上线之后工程师们担惊受怕夜不能寐。其实要从根源上解决这类问题，最好的办法就是搭建一套完善的监控预警系统让工程师能实时的查看系统的运行状态。搭建一套监控系统需要考虑的监控点根据系统的不同略有差异，但一般主要分为以下几个方面。1.用户体检感的监测发布之后我们要能监测到用户端的数据。比如访问速度怎么样，是否会出现超时等现象。针对用户的监控我们可以通过添加埋点的方式来进行监控，也可以通过定

2021在项目中遇到过很多坑,走了很多弯路,这里盘点一下,算是经验教训吧。希望在新的一年里有更多的成长和收获。也希望各位能够通过我的经历,学习到一些东西,争取在未来的开发道路上少走弯路。1.任何一个功能模块都要有运行日志之前的Demo项目开发的多了,养成了不写日志的坏习惯,结果开发一个线上项目没有写日志,这家伙,出问题排查的时候差点没有把自己恶心死和现场运维的沟通的时候也很费劲。所以说开发的时候一定要写日志！！！日志就像警察破案的线索,没有线索警察怎么破案呢?我建议日志在允许的范围内一定要尽可能的写

秒杀系统面临的挑战秒杀活动和类似的抢购活动中,用户会在短时间内集中操作。后台系统可能在一瞬间面临平时几十倍甚至上百倍的并发请求。如果后台系统没有没有足够的冗余资源的话,系统可能被一瞬间搞瘫痪。如何应对短时间内的请求洪峰,让系统正常工作,是一个秒杀系统需要应对的严峻挑战。由于秒杀任务面临的请求是瞬时的,扩充机器数量是不合理的也不划算。如何在现有硬件条件下,应对秒杀活动的海量请求需要从业务流程方面进行优化。下面介绍两种秒杀系统解决问题的设计思路。1.分布式CDN边缘节点促销活动中客户端会不停的请

对于网络应用产品来说,出现线上故障往往是很致命的,会导致用户无法使用产品引起用户流失从而造成经济损失。对于很多靠流量赚钱的网络服务来说，线上故障会直接造成经济损失,还会给企业带来很严重的负面影响。所以如何快速处理系统的线上故障拯救系统,成为了很多网络产品必须要考虑的问题。这里介绍一下自己总结的排查处理线上问题的一些比较接地气的实践思路。问题发生时的那些救命措施问题发生的第一时间需要做的事情,并不是马上找到根本问题把锅甩出去,而是降低由于问题带来的损失。如果是由于新版本更新引起的问题,马上关停新版

系统高可用面临的挑战有哪些?1.资源不可用在实际业务中,出现资源不可用的原因种类可能很多,有的概率很低,比如网线被挖断了,机房失火,地震等等导致网络不可用,有的概率相对来说很高比如服务器硬件资源不足,服务器故障等等。这些问题都可能会导致对应的资源不可用。2.资源不均衡由于系统架构设计的时候没有针对高并发和大流量进行可伸缩设计,导致无法应对并发很大的场景,出现系统瘫痪甚至崩溃。3.节点功能异常这种情况是最常见的,由于代码是人写的,bug和漏洞都是难免的,所以在实际业务中大概率会出现功能