我眼中的云计算6-篇外

        最近发现国内云计算已经可以快跟当年火热的全民股市有一拼了，政府的大力投资和造势，使得云计算概念实在是热得很：LD是会计，在听财务课程的时候，讲师告诉她们未来的财务软件都会在云端，听得云里雾里，回来问我是什么情况；周末亲戚过来玩，聊起来，也问究竟什么是云计算；跟几个业内人士也聊过，从硬件到应用，从构建到使用，想法可谓见仁见智，不过我想除去套取政府的投资外，对云的使用者来说最关键的还是省钱，比如减少一次性投入成本，按实际资源占用付费，节省部署时间，减少维护人员等等，从各种角度降低着开发/运营的成本。

        先看一下云生态链中的典型用户：

        普通用户：作为使用者，桌面环境下仍然是Web方式(选择性忽视CS场景)，数据存放在开发者租用的物理机器还是云端，对普通用户来说并没有什么不同；作为终端的掌握者，应用实在是太多了，乱花渐欲迷人眼，但由于人的习惯问题，一般情况下用户不太经常更换同类应用，而各大软件巨头纷纷涉足终端市场，不但推出自己的终端设备，还争先恐后地开发一键刷机工具，其目的不外乎掌控PUSH信息的能力；前面列举的两种角色是作为消费者，是各类商家竞相争夺的资源，而普通用户同时还是数据的产生者，其浏览习惯/家庭情况/品牌倾向等信息在不经意间被有目的的收集整理，为广告公司的定向投放和精准营销提供基础，但随着隐私信息所引发问题日益曝光，更多的普通用户会关注个人信息的保护，用户需要释放一些诱饵信息以干扰收集者；

        SaaS开发者：根据业务情况，开发者可以选择在Paas或IaaS上构建，实际上Paas/IaaS在系统功能上是相互侵入；采用前者，可以直接使用更多的系统功能，节省开发时间，诸如数据存储的安全(特指数据不丢失，通常有多份拷贝)/缓存/各层的可伸缩性由PaaS提供商来支持；而采用后者则可以得到最大的自主性和控制力度，但随之而来的是系统的复杂性，分发/集群/扩容等全部都要自己来处理；用户数据隔离可以根据需要，最严格时可使用不同的数据库实例，但真正需要采用这种方案的用户选择SaaS解决方案的可能性很小；开发者需要考虑最终用户的体验，快速开发/响应和对系统的控制力需要很好的权衡；

        PaaS提供商：在面对竞争时，开发者的界面友好和底层的可扩展架构都不可缺少，而支持更多的web框架和DB支持让人抓狂；貌似现在PaaS提供商都有着自己的核心应用， 首先满足自身使用需要，再开放数据交互(账号验证/数据查询等)，让第三方围绕着核心功能开发辅助应用，当然也可以开发完全独立的应用，诸如博客，论坛等；PaaS通常集成了Git/SVN等版本管理工具，以方便执行代码部署，但带给开发者太多的不安全感，毕竟辛苦开发的代码暴露在外，风险大；

        IaaS提供商：硬件特别是CPU的高速发展，为了提供资源利用率，减少闲置，从虚拟主机走向云主机，是硬件从单机向集群发展的过程；IaaS抽象了硬件，提供了量化的资源控制和方便的管理接口，把硬件当成软件一样管理：云主机实例的创建/销毁/启动/停止/休眠/唤醒，期间虚拟化扮演者重要的角色；而业内最喜欢提起的云主机应用场景是测试，在需要模拟互联网的大并发用户流量场景时，通过云主机和快照的使用，可以超快的速度部署测试环境，节省了一次性硬件的投入以及大量的安装/部署时间；IDC面临着转型，毕竟收益和竞争压力是不可忽视的；

        再看一下应用的类型：

        业务场景一：最简单的情景，多对一的只读访问，例如新闻页面的浏览，网站编辑完成内容录入后，生成静态页面，用户的请求可根据url直接定位；可产生多份镜像数据，使用CDN或读写分离的方式来优化用户体验，付出的代价仅仅是存储空间和拷贝花费的时间；

        业务场景二：多对一的读写访问，例如电商的物品浏览，相比场景一增加了库存数量/物品评价/最近交易记录等动态信息，通常普通用户的浏览器获得页面框架后，再依次加载动态内容，而为了减少瞬时的异步请求数量或延缓加载压力，动态内容有时候由用户手动点击触发获取；极端情况是秒杀物品，多用户对单一资源的争抢，通常采用分布式锁或先进先出队列的办法，鉴于前端的突发访问量，需要额外准备相应的负载；

        业务场景三：大批量的一对一读写访问，例如SDP/SP业务系统的周/月计费，在计费周期到来时，需要对订阅类型的用户发起计费，由计费结果来决定服务有效期，整个处理过程中存在多次异步等待，如计费发起条件的满足/用户的确认消息/计费结果的等待等；批量多用户情况，但跨用户的数据交互很少，因此可简化为单一用户的处理，负载均衡策略达到较好效果；

        业务场景四：一对多的实时/准实时资源读取访问，例如SNS，用户A关注了多个用户，同时被多个用户关注，当A登录时，系统给所有关注A的用户发送上线通知，获取A所关注用户的在线信息，并按时间顺序显示A关注的用户的发帖；单一用户从系统的多个不同节点加载内容(先不考虑内容的产生时间)，多用户并发情况下则演变为请求从前端向后端分解时迅速增多的模型，各种类型的数据最终在用户的浏览器上完成合并展示，web层负责用户的框架页面/静态信息获取，内存cache管理着索引/在线用户/热用户的信息/及关注者众多的明星用户的发帖，而数据库/文件系统存储着大内容/冷用户等信息；

        业务场景五：一对多的非实时资源读取访问，例如搜索引擎，用户提交搜索关键字后，获得后台返回的网页链接/缩略信息；类似于场景四，但是数据处理/排序的过程在服务端(需要海量的存储空间和计算能力)，而不是用户的浏览器进程；