chapter 1： 搭建可靠，伸缩性好，且易于维护的系统
什么是数据密集型应用？
首先，它是针对计算密集型系统定义的。现如今的大多数应用，核心其实并不在于计算，而在于数据——由此而引发出了一系列现实复杂的问题，比如说海量数据的存储，数据的结构如何设计，如何快速实现数据变更……
数据为应用服务，不同应用的数据结构或特点并不相同，为了适用不同的场景，于是就诞生了很多数据系统：传统数据库（MySQL等等），消息队列，缓存等等，但随着时间的推移，这些不同类型的数据系统呈现出了逐渐融合的趋势，像Redis提供了消息队列的服务，而kafka（Apache 的开源消息队列应用）则提供了像传统数据库一样的持久化功能。而基于数据服务的上层应用，也不再拘泥于单一的数据层服务，而是将服务拆分，根据不同服务的场景和需求选择适宜的数据层，最终各式各样的数据系统被集成了进来。
当多个服务被集成到一起的时候，会引发很多有趣的问题：如何在内部发生错误的时候依然保证数据的正确性，如何处理负载变高的场景等等。所以我们想要的服务应该具有以下特点：可靠性，伸缩性好，可维护性
可靠性：
可靠性包括满足用户期望 ，容错性好 ，满足一般场景下的负载等等。但其实一句话来说，就是我们希望，当出现“错误”时，软件依然可以工作。实际上我们并非苛刻的要求——对于所有‘错误"（包括世界末日，宇宙毁灭），我们的软件都要工作良好，而是说针对很大一部分错误，应该有容错机制或者称之为弹性服务。下面我们来看下那些需要应对的“错误”：
bug: 具体指什么，就不说了，程序员都懂得。要想解决，一方面是测试，另一方面还是要测试......
硬件错误（故障）：对于小规模的系统，这种问题不太常见，但是在很大的数据中心里，每时每刻都会有故障发生。通常规避该问题的常见做法是冗余节点与服务来降低服务整体失效的概率。
软件错误： 常见的有网络拥堵超时，依赖的服务不稳定等等。硬件错误通常是随机独立发生的，不太可能集中出现，而软件错误则可能导致所有在线服务失常。从本质上来讲，我们写代码的时候，总是会假设我们的环境是怎样的，可是有一天当环境变了的时候，故障便产生了。事实上，并没有一个简单迅速的方法去解决这个问题，所以，小心判断你的任何假设！（我忽然想到了防御性编程，应该是针对这种问题的一个不错的方式）
人为错误：据统计，大部分的错误都是人为导致的，软件的编写，构建，部署，操作都是人参与的，but humen is know to unreliable, 所以就软件来说简洁清晰的抽象，易于理解的设计，将易出错的发布环节自动化，尽量减少人的干预，同时做好监控，并且能够紧急回滚。这个其实主要是要提高开发者的水平。
伸缩性（the capacity to be changed in size or scale）：
一个非常拗口的词，哎，计算机行业的词啊，如果我翻译成应变能力的话，是不是也没出入很多，当然这里的应变，主要是指的软件的负载(load)。
高可伸缩性代表一种弹性，在系统扩展成长过程中，软件能够通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。
可伸缩性和纯粹性能调优有本质区别， 可伸缩性是高性能、低成本和可维护性等诸多因素的综合考量和平衡，可伸缩性讲究平滑线性的性能提升，更侧重于系统的水平伸缩，通过廉价的服务器实现分布式计算；而普通性能优化只是单台机器的性能指标优化。他们共同点都是根据应用系统特点在吞吐量和延迟之间进行一个侧重选择，当然水平伸缩分区后会带来CAP约束。
可维护性:
软件的交付通常并不是生命周期的结束，更可能的是一个开始，而且随着时间的推移，参与人员的不断变更，软件会被用来做那些它原本并未打算去做的功能，在这种情况下如何去提高它的可维护性呢？
简单：简单——就是管理复杂度，可以说是我们的终极追求，然而却并不是件容易的事。
随着时间推移，项目在变得庞大，功能变得越来越复杂，让人难以理解。而这样的情况会导致开发的进程受阻，稍微一个功能变更，就可能会引发无法预料的bug。项目变得越来越难以维护。
要解决这个问题，其实要把追求简单与开发功能当做同等重要的事，我们并非要削减功能，而是要移除系统里那些不重要的复杂度（指在用户看来，它不是软件核心要解决的问题）一种很好的方法是找出抽象，虽然很难。（这里强烈推荐DDD(领域驱动设计)）
易于变化：
软件在不断变化，甚至旧的设计已不合时宜，面对变化，敏捷的思想应运而生，给我们提供了框架与理论（TDD: 测试驱动开发 ；重构）局限性：通常敏捷针对的是小的项目与团队。
