一个修行路上的码农

为什么要写好代码？

• 做一个有追求的Coder
• 好的代码能降低整个系统的复杂度
• 好的代码能提高系统的可维护性和可修改性
• 好的代码能提高整体的质量
• 好的代码能提高你得生活品质

公有云已经进入下半场

公有云的发展已经进入下半场，无论是国外还是国内，市场格局已经基本确定，后来者很难再有机会打破现有的格局。纵观国内市场，阿里云一家独大，其他厂商都还在奋起直追，艰难的维持着自己的市场份额。虽然最近两年，不断有大的厂商宣布进军公有云领域，但我认为留给后来者的时间并不多了。公有云是一个强者恒强的行业，随着头部厂商的成熟，厂商锁定(vendor-lock)的现象会越来越凸显，进而越来越多的用户会投入头部厂商的怀抱。虽然，后来者可以在一些细分领域找到某些差异化的优势，但整体格局不会太多的影响。

最近在团队内部分享了一些关于架构设计方面的基础知识，特此分享一下。

项目背景

蜂巢计费系统为网易云基础服务（网易蜂巢）提供整体的计费服务，业务范围涵盖完整的产品售卖流程，包含定价、订单、支付、计费、结算、优惠、账单等主体功能，支持十几种不同产品的售卖，产品形态上贯穿了IaaS、PaaS和SaaS类别。同时，计费方式还提供了了按量、包年包月、资源包等多种方式。该项目的业务范围之广，玩法种类之多，数据要求之严注定了它将成为一个烫手的山芋，而且还是一个吃力不讨好的工作。

该项目在人员上已经几经易手，就我所知，已经换过两拨完整的开发和测试团队了，而且已经全部离职。不得不说，该项目已经变得令人谈之色变，让人敬而远之。在这样的背景下，后期接手的开发和QA不得不硬着头皮上，踩着雷过河，小心翼翼的应对着不断涌来的业务需求。随之而来的是高居不下的bug率，越来越难以维护的代码，无法扩展的架构问题，我们开始意识到这样下去是不行的。于是我们从8月份开始了漫漫的架构升级之路。

相信很多人都听说过二八定律，这是一个适用性非常广泛的定律。我发现二八定律同样适用于软件开发，并对其产生了十分深远的影响。这次我想聊聊二八定律是如何影响我们日常的开发工作的，希望通过这个话题来改变一下大家习以为常的开发思维。

写在开头的话

想写这个系列文章很久了，但是对于一个重度的拖延症患者来说，决定写一个系列文章还是颇有挑战。最开始，只想写一两片文章分享一下自己对于编程的感悟。但随着时间越拖越久，发现想写的东西越来越多。直到今天，居然发现我的博客的To-Do-List（目前我在使用WunderList，很好用的一个To-Do-List工具)文章数达到了10篇，终于说服自己动笔了。
“编程心智”这个词这段时间一直萦绕在我的脑海中，我觉得这个词最能表达我想分享了内容了。我希望通过这个系列文章分享自己对于代码、编程、架构以及软件工程的理解与感悟，另外，还有隐藏在代码后面的程序员心智。所有文章仅代表个人观点，没有是非对错的标准。如果你对文章中的观点不认同，还请给我留言，不同的声音对于进步有着极大的促进。

我以前写过一篇关于领域事件的文章——实现领域事件，随着在项目中深入的使用DDD架构，我对领域事件有了新的认识。尤其是采用领域事件来解耦代码这种方式对项目的发展具有深远的影响。

最近网易云上线华北REGION(cn-north-1)地区的服务，在此过程中我们做出了很多调整以适应跨REGION架构。

昨天QA跟我反馈说系统有几个接口反应很慢，起初我不以为意，因为这几个接口就是简单的写入和删除，最多就是再更新一下缓存，能有多慢。我让QA看看是不是网络抖动，延迟的问题，再看看我们的access_log里面响应时间是多少。QA说网络比较稳定，access_log里面显示要好几秒，这就让我有些诧异了。其中有一个删除用户XXX数据的接口响应特别慢，我们在测试环境去复现的时候果然复现了这个问题。当前端直接点击删除的时候，接口过了8秒多才返回，这肯定不正常了，而且access_log也印证了这一现象。

昨天看到一篇关于“架构师”的文章，读后非常有感触。我个人比较认同作者的大部分观点，故决定将原文进行翻译，和国内的开发者一起分享。原文地址：“Architect” Should Be a Role, Not a Position”。