web项目上云的思考

      对于传统的web项目来说，上云（公有云）部署，在技术成熟度是比较高的；目前公有云IaaS类业务可以支持数据库、分布式缓存、负载均衡等web相关的挂件组件。这里主要讨论下，应用上云之后，技术上的优劣势和管理上的问题。本文主要分析以本人在国内某大型电商网站的私有云/公有云建设的经验为背景。
技术看：

功能。公有云在IaaS层熟度非常高，在PaaS级别有一定缺失，例如一些公共组件，公有云厂商支持的不多，例如ESB（企业服务总线）、跨语言的RPC、站内搜索、日志采集分析、统一配置管理、邮件短信平台、应用监控等；这点都可以将原有业务部署在IaaS的虚机上变通的方式来解决，即自己做PaaS；外对于中小型项目，对于PaaS的需求并没那么高；

性能和稳定性。性能方面的主要风险是公有云厂商承诺的硬件指标是否跟实际相符；云环境肯定是存在物理资源超分的。以笔者的经验看，cpu和内存的超分风险并不大，风险主要在网络和存储io；现代计算机的瓶颈还是在网络和存io上，用户数量突然增高的高并发的场景下，首先出现的瓶颈还是磁盘速度太慢或者网络带宽不足。厂商承诺的网络带宽和block
iops，是否能保证7*24都有这么高，肯定是疑问的。公有云是个大杂烩，举个简单的例子，公司的邮箱的文件服务器和im通信的数据库，放到了云的同一个物理机上；业务闲时互补影响，上班早高峰期，很多用户同事打开im，收发邮件，这个时候，该物理机的blockio和网络io都会很高，如果是在私有云里，用户比较容易发现也可以做迁移，如果是公有云，用户是不知道的，只会发现自己的虚机在高峰期的性能有抖动。 因此，上云之后的拷机和压测，要比自己的IDC里面要更严格。
扩展性。扩展性方面公有云具有天生的优势，用户不需要投放精力在购买服务器、交换机等IT基础设上，连安装操作系统都可以省去了。需要考虑的风险点主要是用户自己的应用架构，是否cloud native的，即，用户自己的应用架构，是否可以scale-out水平扩展。如果用户自己原有的架构严重依赖单机硬件的超高性能，那么放到云上很困难，公有云厂商很难为少数用户定制超高性能的硬件服务。
运维。应用搬到云上之后，不再需要运维人员自己去插拔网线，更换硬盘，这些事情都交给公有云的运营商了。但是运维的响应时间会变慢了。运营商的服务器硬盘也会坏，出问题的时候要自己提单给厂商让厂商迁移、维护虚机。简单的说就是用户的单台虚机异常了，需要用户自己的应用架构保证服务不中断，QoS不受重大影响，可控的时间内完成虚机的迁移或者重建，就可以搞定问题。
监控、告警。上云之后，用户只能监控到虚机级别物理资源。如果用了公有云厂商的paas，还要把用户自己应用监控跟厂商的paas对接。物理机级别的监控，不清楚是厂商如何通知到用户。

   管理的挑战可能更需要时间来解决：

持续集成、告警监控系统与公有云的融合。上云之后，开发测试环境是否也部署在云里面，如果有自己的持续集成平台，是否也部署在云里面。原有的办法发布流程如何调整，比如申请域名，申请WAF等。
公司研发内部开发、运维、QA职责的调整和融合。无论采用公有云/私有云模式，都对于研发团队敏捷性有更高的要求。研发、运维不能再以物理资源不到位作为拖延的理由。而运维团队日常硬件巡检的工作可以解放出来，但在云环境的部署和监控的要求更高。而且运维团队原来机器打交道，现在想跟机器打交道需要先找公有云厂商的客服。
公司内部云资源申请的审批和调控。 IT资源的成本更加可控，公司的业务和财务部门第一时间就能拿到研发团队的成本预估，而且可以按需分配，资源不够再购买即可。

    总之，上云之后，资源分配速度得到极大加快了。换言之，研发节奏加过了，那么，对于整个公司管理风格的灵活性，研发团队的敏捷性，要求更高。