我眼中的云计算-写给自己

        很多人，甚至行业外人士，都熟知摩尔定理，但与之关联的另外一个安迪比尔定理(What Andy gives, Bill takes away，见吴军博士《浪潮之巅》)，知名度远不如前者，大体的意思是随着操作系统的升级，硬件改进所带来的性能提升都会被耗尽；很多时候都会听到这样一句话，“新的硬件会满足客户的要求，先别考虑性能”，硬件的升级反过来变成了某些项目的救命稻草；

        受硬件条件所限，分布式系统的设计遵循CAP定理：一致性（Consistent）、可用性（Availability）、Partition Tolerance（分区容忍性）三个属性不可能同时满足，需要做出取舍；随着信息产业的发展，系统的复杂度不断增加，不同业务系统间的交互越来越多；从"分布式系统"的名称来看，显然分区容忍性必须要考虑，那么一致性和高可用性间需要进行权衡和比较,而不同业务系统的时效性有着不同的要求，那么必然要在高可用性和数据一致性取一个折中；可用性的要求，暗含了多机的需求(主备，互备，多机集群)，最终一致性似乎成了多数人的选择，不过我们可以从下图看出当前的解决方案在CAP间的取舍；也许只有当运算速度超过现今计算机10万倍，能源消耗为十亿分之一，存储空间为百亿亿分之一的生物计算机出现时，CAP难题也许会被破解，毕竟现在Google的服务器也只是百万数量级，活在当下则继续根据业务情况进行必要的取舍吧；

        “一屋不扫，何以扫天下”(且不管这句话是不是杜撰的)，在挖掘单机性能之前，就使用集群来提升性能，一是增加了复杂度，二是增大了成本，当然系统的可扩展性是必须考虑的问题；让我们先看看都有哪些策略来提升性能：1.优化执行频率大的代码块，减小时间复杂度，特别是嵌套循环；2.分析数据的生命周期，省略中间数据的IO，使用缓存，变随机IO为顺序IO；3.减少同步和阻塞的使用，利用多线程和异步操作来提高CPU的利用率；4.利用CPU新的指令集，如CAS的原语操作，CRC32C等；5.选择合适的数据结构，减少中间对象的生成数量，更高效率的线程访问能力；6.特定业务环境下的开源软件优化，

        分而治之(Divide and Conquer)，可以理解根据业务情况对功能进行分层，当单机无法支撑业务量的增长时，通过多机集群来提供服务，分发按发生的位置，一般是四层和七层，分别对应着OSI的传输层/应用层(实际上四层分发需要使用三层的VIP和四层的端口)，对应的软件解决方案则是LVS和Nginx，通常四层分发可以提供更高的性能，而七层分发则有更好的准确性，如http的url分析；

        可以想见，“实现任务到资源的最优分配”- 调度是“分而治之”模式的核心问题，而且调度粒度越精细，资源消耗的控制才能越精确；但是精细粒度的任务调度也带来更高的调度开销，需要根据业务情况权衡；调度最终和最重要的目标是吞吐量(指定时间段内完成的任务数，以及用户分级/业务分组的能力/流量控制)，响应时间(这里主要考虑处理时间，暂不考虑传输时间)；

        对于调度器而言，资源是客观存在的硬件限制，主要有：计算能力，内存容量，内存带宽，网络带宽等；而任务则是要利用资源解决的问题，相对资源而言比较复杂，可能存在的情况有：任务之间存在依赖关系，任务在不同物理节点上对资源的占用有差别，任务对不同资源的利用程度不同，硬件资源有限，任务对处理资源有要求，只能在特定资源上执行；平衡资源和任务的调度算法则有有：轮询(Round Robin)，随机(Random)，权重(Weight)，Hash(IP/Cookie)，负载(System Load)；分布式系统架构里，调度算法所在的位置也有多种选择，大致有：服务端模式，客户端模式，客户端模式+管理节点；

        业务压力经过接入层和业务层的处理，不可避免的会传输到持久化层，而CPU运算能力的提升远远超出磁盘容量和IO能力的提升，磁盘在存储空间还是读写IO能力方面所能提供的支持远远不足，必须以数倍/数十倍于计算节点数的磁盘提供服务，显然文件系统也必须提供分布式支持；而业务情况的差异性，使得同源(Google的GFS)的分布式文件系统实现各有千秋，适应大文件流式读取的HDFS，满足小文件随机读取的TFS等；基本架构差别不大，都是NameServer+DataServer，NameServer的高可用性都还待解决，block的设计由于文件大小和修改特性的支持有较大差别，额外的业务管理模块；

        因为数据持久化的要求，一般情况下分布式数据库相比分布式缓存的设计要复杂，因为缓存可以通过重建来忽略数据迁移的成本；一旦单库不能满足业务持续增长的需要时，请求读写的比例，写请求里临时性数据与持久性数据的比例，持久性数据间的关联程度，数据的规模，数据展示检索的根属性，都影响着数据存储层扩展策略的选择：master-slave(读写比大),master-master(读写相对平衡)，vertical partitioning(基于功能,彼此间无关/不需join的数据), horizontal partitioning/sharding(大表拆分，按抽象的层次可分为server级，database级, table级), partitioning/sharding key(sharding的依据选择)，Range-based Partitioning(无法平衡热点数据的分布), Hash-based Partitioning(一致性Hash通过虚拟节点减少了扩容时数据迁移的数量), Mod-based Partitioning(唯一key的生成策略), Lookup-based Partitioning(最自由，需要付出多次交互的代价), rebalance(由于Partitioning规则变化/数据节点扩容带来的数据迁移)；

        技术能力的提升，一般是初步掌握->“实践->总结->朴素的理论->吸收大师/先行者的成果“这样的螺旋式上升；自己的知识结构完成基本归纳和建立索引后，每一个新领域的接触，首先扩展知识结构的广度，而实践中所遇到的问题能从原理上解决的话，则使知识结构的深度得到拓展；"工欲善其事，必先利其器"，为了让更好的构建系统，除开对运行环境/容器/框架的基本使用外，还掌握了以下个人感觉必备的知识：硬件架构(MESI协议，存储机制)，多线程(业务逻辑的拆分，线程池的使用)，同步锁(资源争抢时的处理，加锁代码块的范围，读写锁的使用，悲观/乐观锁的使用，CPU原语的利用)，索引(hash，B+树的使用)，语言(工具类，开发框架，运行环境，代码块优化策略，编译优化策略)，搜索引擎(自然语言的处理，索引的建立，混合语言的分词)，操作系统(进程线程模型，网络IO模型)，辅助工具(更好的优化定位问题，如监控耗CPU的代码块，耗内存的对象，系统调用的百分比等)等等；越多的知识储备可以让系统构建时的不确定性越小，团队成员技术储备如何能够互补则是完美的；

        Don't do it if you don't need to, but prepare for when you do.