公有云的发展已经进入下半场，无论是国外还是国内，市场格局已经基本确定，后来者很难再有机会打破现有的格局。纵观国内市场，阿里云一家独大，其他厂商都还在奋起直追，艰难的维持着自己的市场份额。虽然最近两年，不断有大的厂商宣布进军公有云领域，但我认为留给后来者的时间并不多了。公有云是一个强者恒强的行业，随着头部厂商的成熟，厂商锁定(vendor-lock)的现象会越来越凸显，进而越来越多的用户会投入头部厂商的怀抱。虽然，后来者可以在一些细分领域找到某些差异化的优势，但整体格局不会太多的影响。
最近在团队内部分享了一些关于架构设计方面的基础知识，特此分享一下。
蜂巢计费系统为网易云基础服务（网易蜂巢）提供整体的计费服务，业务范围涵盖完整的产品售卖流程，包含定价、订单、支付、计费、结算、优惠、账单等主体功能，支持十几种不同产品的售卖，产品形态上贯穿了IaaS、PaaS和SaaS类别。同时，计费方式还提供了了按量、包年包月、资源包等多种方式。该项目的业务范围之广，玩法种类之多，数据要求之严注定了它将成为一个烫手的山芋，而且还是一个吃力不讨好的工作。
该项目在人员上已经几经易手，就我所知，已经换过两拨完整的开发和测试团队了，而且已经全部离职。不得不说，该项目已经变得令人谈之色变，让人敬而远之。在这样的背景下，后期接手的开发和QA不得不硬着头皮上，踩着雷过河，小心翼翼的应对着不断涌来的业务需求。随之而来的是高居不下的bug率，越来越难以维护的代码，无法扩展的架构问题，我们开始意识到这样下去是不行的。于是我们从8月份开始了漫漫的架构升级之路。
相信很多人都听说过二八定律，这是一个适用性非常广泛的定律。我发现二八定律同样适用于软件开发，并对其产生了十分深远的影响。这次我想聊聊二八定律是如何影响我们日常的开发工作的，希望通过这个话题来改变一下大家习以为常的开发思维。
想写这个系列文章很久了，但是对于一个重度的拖延症患者来说，决定写一个系列文章还是颇有挑战。最开始，只想写一两片文章分享一下自己对于编程的感悟。但随着时间越拖越久，发现想写的东西越来越多。直到今天，居然发现我的博客的To-Do-List（目前我在使用WunderList，很好用的一个To-Do-List工具)文章数达到了10篇，终于说服自己动笔了。
“编程心智”这个词这段时间一直萦绕在我的脑海中，我觉得这个词最能表达我想分享了内容了。我希望通过这个系列文章分享自己对于代码、编程、架构以及软件工程的理解与感悟，另外，还有隐藏在代码后面的程序员心智。所有文章仅代表个人观点，没有是非对错的标准。如果你对文章中的观点不认同，还请给我留言，不同的声音对于进步有着极大的促进。
最近网易云上线华北REGION(cn-north-1)地区的服务，在此过程中我们做出了很多调整以适应跨REGION架构。
昨天QA跟我反馈说系统有几个接口反应很慢，起初我不以为意，因为这几个接口就是简单的写入和删除，最多就是再更新一下缓存，能有多慢。我让QA看看是不是网络抖动，延迟的问题，再看看我们的access_log里面响应时间是多少。QA说网络比较稳定，access_log里面显示要好几秒，这就让我有些诧异了。其中有一个删除用户XXX数据的接口响应特别慢，我们在测试环境去复现的时候果然复现了这个问题。当前端直接点击删除的时候，接口过了8秒多才返回，这肯定不正常了，而且access_log也印证了这一现象。
昨天看到一篇关于“架构师”的文章，读后非常有感触。我个人比较认同作者的大部分观点，故决定将原文进行翻译，和国内的开发者一起分享。原文地址：“Architect” Should Be a Role, Not a Position”。