最近,博客园在技术升级上作了积极向上的努力,虽然中间过程出现反复,但姑且先不论最终升级后客户体验方面的提高,在升级过程当中探索排查问题和解决问题的过程,自己就能帮助博客园团队和广大用户积累经验和提高能力,这种实践机会是千金难买的。docker
阅读了博客园官方的相关文章,其中充满对广大用户浓浓的善意,这从多数一样充满关心的回复里能获得充分体现。其实,博客园团队在本次乃至以后的升级过程当中,不妨作得更自信些,毕竟博客园的技术实力和品牌摆在这里。并发
从结果上来看,若是本次过程放在通常的互联网公司,不能不算是个产线问题,有差异的是博客园交流技术的氛围浓厚,不大会所以流失用户。不过博客园管理团队依然能够思考以下的问题。负载均衡
1 对于升级后的技术方案,针对当前并发流量,有没有作过压测?框架
2 有没有事先评估升级过程当中可能会出现的问题,并以此作了回退等预案?高并发
3 高速开车换底盘的过程当中,通常会用灰度发布的方式,一点点切流量,目的是对现有产线影响最小。本次升级,发布次数众多,是否是每次都是全量切换?性能
总之一句话,能够分析本次有哪些改进点?若是再作一次,怎么能作得更好。复盘问题,是为了让以后的升级更加平坦,也是为了让以后的升级更加自信。学习
我常常见到阿里团队,在各类场合从框架角度介绍他们的组件或产品,并且很多框架和技术会在介绍后,影响面逐渐扩大,以后该组件或框架逐渐成为业内标杆。博客
好比如今咱们要解决某个高并发等方面的问题,首先会想,阿里或其它著名互联网公司是否有现成的解决方案。与之对应,我所但愿看到的场景是,博客园所采用的基于.NET的框架体系,也成为业内的标杆,若是有人在.NET方面有问题,首先会想,博客园对此是怎么解决的。这样的话,就单论技术层面,博客园的影响力也能进一步扩大。产品
虽然我是作Java的,对.NET不大熟悉,但从本次博客园相关官方文章里,能看到很多“docker”,“云”,“高并发”和“负载均衡”等热门词汇,这说明博客园所用的技术第一不算落伍,第二还紧跟技术进步的潮流。在这基础上,在不涉及到商业机密的前提下,博客园能够更为自信地在众多场合介绍自身的技术框架以及相关技术实践,好比介绍应对高负载的.NET体系框架方案。基础
但愿不久的未来,能在诸多技术大会等场合,听到博客园技术人员能自信满满地介绍本身的框架,底下是顶礼膜拜的广大听众。
本次版本迭代,影响面不小,但不能所以缩手缩脚,相反还能够更自信地完善技术乃至完善版本发布流程,毕竟博客园的技术储备摆在这里。
我期待的博客园发版流程是,首先举重若轻地通告,从某月某日某点到某点,进行发布;其次在发布过程当中,虽然会出现个别功能故障,但整体不会出现大问题;最后是写篇文章总结,好比在本次发布过程当中,用到了xx技术,从功能上作了xx提高,在性能上有xx改进。
这其实也是诸多互联网公司广泛流程,通常都是一月两版本,甚至更多,每次发布虽然重视,但绝非如临大敌。
发布时的自信来自平时的不断总结以及充足的预案,只要不中止探索,一回生二回熟,成功次数多了,自信心就慢慢提高上来了。
在博客园发展的路上,咱们不该该仅仅作看客。
第一,先不说写博客,就先说在评论别人博文时,应当注意影响,在争论不一样观点时也应当尽可能心平气和,毕竟在博客园发表不堪的文字,更会让博客园美玉有瑕。
第二,看到博客园偶有功能上的问题,乃至本身想到有改进点,能够找个合适的场合与博客园沟通。
第三,尽可能多写些有质量的原创博文,好比在写文章前多找些素材,用词造句时多斟酌,多加入些本身的思考。
第四,若是以当前的能力,写不出足以留在首页的文章,也能够经过不断学习提高本身的能力,经过不断写做提高本身的文笔,这样文章的质量就慢慢提高了。
本人对.NET技术不熟,因此在本文里也不敢据此提出此方面的看法,在最后也但愿能抛砖引玉,引出更多高质量的相关技术文章。