在我们开发的诸多系统，基本都可以视为“数据密集型系统”，数据是一切物质的载体，我们依靠数据做存储记录，通过数据进行信息传递交换，最终还要数据来呈现和展示等，从一定视角而言，系统中最核心、最底层、最密集的是数据，时刻都在围绕数据构建服务运转并驱动业务。

1. 系统服务在承载哪些职责

我们先来思考几个比较本宗的问题 ——— 我们为何要开发一个系统？怎么体现一个系统的好坏？系统在为谁服务？

为何要开发一个系统？

在当前这个信息化、互联网的时代，软件系统已经根入到生活生产、衣食住行的每一个环节，无论是ToC或ToB业务，无论是天上飞的还是地上跑的，都有软件系统存在的身影。从最朴素的视角出发，我们是在用软件工程、技术手段来构造一个组合要件，完成功能满足需求，让它的形式看起来像一个整体，来服务一定范围的业务或者人群，并且会存在一定生命周期的持续性技术集合，在服役期间要尽最大能力达成业务诉求，要做到运转稳定、数据准确、体验良好等，最终收益是通过技术投入来助力业务运作的高效收益。

怎么体现一个系统的好坏？

随着承载业务的发展，系统也在随之变化，大部分时间是从0.0.1到0.0.2的逐层迭代，也会有1.x到2.x的改造升级甚至重构。小改动是量变，可以是功能优化，也可以是问题修复，投入可控，挑战不大，大改动是质变，非常考量团队及个人的能力水平，是对系统前期搭建可塑性、扩展性的考验和回溯，成功的质变带来的是无穷无尽的能量，它能紧跟业务的迭代进行适配推动其蓬勃发展，而糟糕的劣变会让系统埋下雷区，让团队成员疲惫不堪，从而与业务节奏脱节。

因此，一个大部分人眼里好的系统不应仅仅是让上游业务使用者感觉”厉害“，还要让参与系统开发、维护的参与者们感觉”舒适“，既要外表光鲜，也要自得其所。能够同时满足以上两点在诸多的项目实践过程中的确很难，但是如果能做到的确很棒，这就是一个”好系统“的标准。

系统在为谁服务？

基于上述，我们可以从系统使用者、系统建设者两个方面进行划分：

• 对服务使用者「用户」 的功能交付，用户具有上帝视角，用户反馈是系统服务成败的关键一环甚至是最核心一环，一切都是为了使用者更好的体验
• 对服务建设者「研发」 的投入反馈，方案是研发做的，代码是研发敲的，合理不合理，是否可扩展可维护，可以看做是自己的因来种自己的果，抛开第一层用户交付，其他全是研发自身建设的驱动内循环，可维护可拓展较为丝滑的迭代体验来自于前期良好的设计与实践。

服务承诺：更高、更快、更强

SLA (Service Level Agreement)，即服务级别协议，是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。

运动场上的健儿们追求的目标是奋力夺冠，技术角逐中研发小伙儿们的目标是打造"三高"。

• 『高并发』 如何花最少的资源做最多的事情？如何让最少的投入获得最大的产出？这是一个非常考究的话题，高并发意味着高吞吐，在一定时间内可以处理更多的事情，在同样的资源投入下，有的系统可以同时处理上万请求，有的系统只能处理几百，这场景最熟悉的莫过于去银行办理业务了，如果一个银行只能开一个窗口，所有用户无论什么业务都只能one by one串行等候，这种体验让人一言难尽，如果这时银行开窍了，增开窗口，而且还把办理不同业务的人拆分开，加快办理速度，”并发“噌的一下就上来了，正如魔兽世界地精的那句开场白”时间就是金钱，我的朋友！“，高效率的系统能力必然带动业务的高增长，这才是真的”快“。
• 『高性能』 性能永远是一个迷人的话题，迷人之处在于每一次小小的进阶都是一次极限的突破，而每一次小小的变化来自于强大的知识积累和实践新知的融合。图灵奖获得者尼古拉斯•威茨说到”程序=数据结构+算法“，当参与了诸多项目开发，经历过诸多性能优化的实践，尤其是碰壁过很多困难和陷入窘境的时候，这句话就非常具有指导意义，前面提到系统开发的三层概念，数据层、应用层是研发大展身手的地方，也是最能体现这句话深谙含义的地方。微观来说，各种数据结构决定了查询、更新数据的时间复杂度，选择合理的数据存储结合巧妙的算法特点可以使得数据处理事半功倍；宏观来说，熟练的组合和编排中间件充分发挥他们的优势和特点，让正确的东西做正确的事情，形成整体收益，这才是真的”高“。
• 『高可用』 相信当你作为一个用户使用产品时，宁可反应慢一点、界面丑一些都能暂且忍受，就是不能接受系统直接”暴毙“不能用。高可用的要求是”三高“的底线，是最不能被突破的一环，当你设计的技术方案搭建出了可靠的系运转体系，经过业务极限的洗礼后屹然不倒，就像狂风呼啸过那山岭仍稳如磐石，这才是真的”强“。

内省心法：靠得住、看得懂、改得动