EBIT，全称Earnings Before Interest and
Tax，即息税前利润，从字面意思可知是扣除利息、所得税之前的利润。计算公式有两种，EBIT＝净利润＋所得税＋利息。
或EBIT＝经营利润＋投资收益＋营业外收入－营业外支出＋以前年度损益调整。
EBITDA，全称Earnings Before Interest, Tax, Depreciation and
Amortization，即息税折旧摊销前利润，是扣除利息、所得税、折旧、摊销之前的利润。
计算公式为EBITDA＝净利润＋所得税＋利息＋折旧＋摊销，或EBITDA＝EBIT＋折旧＋摊销。
EBIT主要用来衡量企业主营业务的盈利能力，EBITDA则主要用于衡量企业主营业务产生现金流的能力。
个人注：我们公司的酒店就是用EBITDA这个指标来衡量的。
作者说得好“我们之所以研究历史，不是为了要知道未来，而是要拓展视野，要了解现在的种种绝非‘自然’，也并非无可避免。未来的可能性远超出我们的想象。......历史总是这样从一个岔路走到另一个岔路，选择走某条路而非另一条的原因总是神秘而不可知。”
就像书中所说，人类从一种食物链中端的生物，发展到现在类似上帝的存在，其中的每个关键步骤都是超乎当时人们的想象的。
本书从智人的认知革命说到了现代科学革命。智人开始发展出新的思维和沟通方式（新的语言），这种认知的革命，开始让智人站上了生物链的最顶端。认知，让智人能想象出现实世界中不存在的事物以及虚构的故事、让智人能够组织更大规模的合作和创新，就这样，智人扩展到了整个地球并主宰了地球。
1、易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
2、大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query
Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
3、灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
4、高可用
NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
总结
NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。
MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。
SOA：
开源的做的比较好的，大公司的服务框架有：dubbox和Motan
dubbo最先是阿里开源，当当改造为dubbox，使用面最广
Motan是微博的开源
MQ：
Apache ActiveMQ和RabbitMQ用的比较多
本文着重介绍sharding的基本思想和理论上的切分策略，关于更加细致的实施策略和参考事例请参考另一篇博文：数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示
Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.
Node.js现在非常活跃，相关生态社区已经超过Lua（基本上比较知名的功能都有nodejs模块实现）。
但是我们为何要使用Node.Js？相比传统的webserver服务模式，nodejs有什么优点优势？
Node.Js是基于javascript语言，建构在google V8
engine以及Linux上的一个非阻塞事件驱动IO框架。nodejs是单进程单线程，但是基于V8的强大驱动力，以及事件驱动模型，nodejs的性能非常高，而且想达到多核或者多进程也不是很难（现在已经有大量的第三方module来实现这个功能）。
这里主要不是介绍nodejs具体应用代码，而是想介绍一下事件驱动编程。
在这篇文章（1）里面，Dan York介绍了两种典型的事件驱动实例。
对于读大于写并且数据量增加不是很明显的数据库，推荐采用读写分离+缓存的模式，试想一下一个用户注册、修改用户信息、记录用户登录时间、记录用户登录IP、修改登录密码，这些是写操作。但是以上这些操作次数都是很小的，所以整个数据库的写压力是很小的。唯一一个比较大的就是记录用户登录时间、记录用户登录IP这类信息，只要把这些经常变动的信息排除在外，那么写操作可以忽略不计。所以读写分离首要解决的就是经常变化的数据的拆分，比如：用户登录时间、记录用户登录IP。这类信息可以单独独立出来，记录在持久化类的缓存中（可靠性要求并不高，登陆时间、IP丢了就丢了，下次来了就又来了）
以oracle为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操作，同步更新cache，每次读取先读cache再读DB。写库就一个，读库可以有多个，采用dataguard来负责主库和多个读库的数据同步。
我们正式开启JavaScript的后端开发之旅。
简单的说 Node.js 就是运行在服务端的 JavaScript。
Node.js 是一个基于Chrome JavaScript 运行时建立的一个平台。
Node.js是一个事件驱动I/O服务端JavaScript环境，基于Google的V8引擎，V8引擎执行Javascript的速度非常快，性能非常好。
此时的ORM工具、事务控制手段、简化CRUD是重要的关注点。职责分离，针对需求不同对服务器进行不同的配置（或采购），对应将依赖程度较高。
为了提高响应速度和避免不必要的请求，增加了页面缓存；为了应对有限的I/O资源，增加了数据缓存。在对数据修改时，同时修改缓存内容。
随着数据越来越多，缓存也逐渐变成了分布式（Memcached、Redis等等），对于分布式缓存的使用主要存在几种情况：
在服务化架构中，消息队列的作用时不可替代的。服务化架构的异步通信、流量消峰、跨语言调用、通知协调等等很多功能都会用到消息队列。
在选用MQ时，要考虑一下我们的需求和MQ自身功能是否匹配，超前的使用有时候并不能给我们带来相应的好处，反而可能会成为使用的障碍。
消息队列有点对点（point to point，
queue）与发布订阅（publish/subscribe)等方式。
Sender（Producer App）——Message Queue——Receiver（Consumer App）
消息队列的出现意于完成系统间的消息通信，协调系统调用间调用。这跟SOA类似。但不同于SOA面向服务的直接调用，消息队列的通信不是直接调用关系，系统间通信主要通过消息发送，接收方接收消息，进行处理，完成与发送方的调用处理。