你好,游客 登录
背景:
阅读新闻

移动互联网初创团队7大云计算服务实践分享

[日期:2013-12-17] 来源:CSDN  作者: [字体: ]

  正是有了云计算,才有了移动互联网初创企业的大爆发。来自云计算深度用户的一篇投稿,用实践告诉大家如何找到小而美VPS云主机,怎么应对峰值带宽的云存储,MySQL服务和NoSQL数据库如何使用,以及云安全和云监控的实现方法。欢迎更多一线技术爱好者投稿@CSDN云计算或cloud@csdn.net,我们将开辟专栏,为云计算的读者们构建起深度交流和分享的平台。

  以下为文章内容:

  对于创业型团队来说,服务器托管费用+带宽成费用+运维成本,是压在头上的三座大山。满足业务性能需要,又要降低成本,尽快实现收支平衡,是当务之急。

  一、 对App Engine使用要慎重

  1、Google App Engine 云服务在国外的成功,不代表国内巨头们各种 *AE 仿造品的成功。在微博上搜搜就可以看到小伙伴们吐槽的各种不稳定,另外,*AE们对资源使用最大数各种规定限制,加上为了计费、阉割功能的各种限制,使它 的价格优势成为鸡肋。*AE们就好比100M共享带宽的小区宽带,以低价卖给每个上网用户5M的带宽,前几十个用户感觉这网速真不错,等他卖了100个以 上用户5M带宽,而这部分用户白天上班去了,晚上下班回来都在上网,其中又有一部分看视频、BT下载,于是乎,白天网速快,晚上慢得要死,连200K带宽 都达不到。要知道,不怕神一样的对手,就怕猪一样的队友,在国内的 App Engine 环境下,水平参差不齐的开发者的代码质量、习惯性的资源滥用、别人网站被攻击殃及池鱼对*AE性能的影响,导致*AE的稳定性非常差。

  2、所以,*AE们也意识到公共 App Engine 不稳定,所以又推出专用 App Engine,但费用一下就翻了很多倍。所以,*AE只是个人博客、个人开发者玩玩的工具,真正用作项目,还是需谨慎。根据实际的经验,*AE们还真不如VPS稳定。

  二、成本低的小而美VPS云主机

  1、对于初创团队来说,购买服务器、交换机,托管服务器费用、带宽月使用费,是极其昂贵的。购买可以弹性升级硬件配置的云服务VPS,是降 低成本不错的选择。国内VPS,1G内存、1~2核CPU、1M带宽、多线BGP,大概价格在100元/月左右,支持备案,可以作为最低入门选择,有条件 可以购买两台互为热备,阿里云主机可以作为参考。大多数VPS服务商使用的都是廉价的SATA磁盘。如果你对磁盘IO要求较高,可以选择提供有SAS磁盘 的IAAS云主机服务商,比如UCloud。

  2、市场上的VPS商家主要有 Xen、OpenVZ、KVM 三种开源的虚拟化技术。全虚拟化的 Xen 更像独立主机,服务器资源按VPS实际大小平均分配,一般无法超售。半虚拟化的 OpenVZ 在同样的性能测试下,会比 Xen 高一些,但是,一台物理内存16G的服务器,可以分配出总内存大小超过16G很多倍的VPS,服务商可以超售,想卖多少台VPS就可以卖多少台,所以不推 荐使用。KVM 在最新的 Linux 发行版中,已经是集成,但是,商业化应用还不成熟,基于 KVM 的 VPS 服务商很少。

  3、VPS的操作系统,建议选择64位的Linux。在32位Linux下,PHP能给处理的整数不能超过正负 2^31=2147483648,如果以后接入新浪微博、淘宝、腾讯等第三方开放平台,他们的接口里会有超过32位的整数(比如新浪用户ID、淘宝商品 ID)。如果不幸使用32位Linux,你只能将这些整数当成字符串处理了,以后配合Sphinx等搜索引擎,会非常麻烦。

  4、现在,可以在北京进行备案的域名有:国际域名 .com .net .org,国内域名 .cn . com.cn.中国,国别域名 .cc,其他的域名均不能进行备案。仅北京有限制,其它省市正常提交备案即可。我们原来申请的 .me 域名,在北京无法备案,后来只好拿到苏州去备案了。所以,在选择域名的时候,需要慎重。5、使用 VPS,一定要定期在本地,做好数据备份,不要相信所谓的 7*24服务,99.99%安全稳定性,只要有人的VPS出问题了,都归为那 0.01%。

  三、应对峰值带宽的云存储

  1、对于DAU(日活跃用户)过十万的网站、APP应用来说,CDN或云存储是必需品。使用云存储不是因为存储空间,因为一块几TB的 SATA磁盘很便宜,使用云存储是因为高出平均带宽值几倍至几十倍的峰值带宽。做手机APP应用,峰值带宽更集中,当你向所有用户群发PUSH一条消息, 用户被唤醒打开APP应用,几分钟的时间,会消耗几十倍的带宽峰值。图片、下载,是最主要的带宽消耗者。也许,数据接口API只需不到1M的带宽,而图片 对带宽的峰值需求则会达到100M。为了几分钟的峰值,去购买100M昂贵的带宽,其他时间带宽都空闲,是一件非常奢侈的事。对于大量的图片以及体积较大 的文件来说,使用云存储相对自己部署源站+第三方CDN要具有一些优势:一是节省的本地存储及热备的硬盘空间;二是节省了CDN缓存未命中时的请求的双重 带宽消耗(CDN带宽和源站带宽);三是支持一些类似图片裁剪、图片防盗链的特殊功能。

  2、国内提供云存储服务的商家有很多,真正好用得却不多,提供FTP等公共通用协议的云存储更是微乎其微。使用第三方云服务,切忌千万不要 吊死在一棵树上。支持FTP等公共协议,如果将来有问题,能够方便的进行数据迁移和技术替代。如果云服务厂商一直能够提供优质的服务,那么,也就可以长期 使用他们的云服务。相信优秀的云存储提供商,是不会惧怕这一点的。

  本人博客的图片、附件下载,使用了又拍云存储。相比于其他的云存储,又拍云支持FTP上传、下载管理文件,同时对于图片类文件的处理功能,也比较强大: (1)、支持缩略图&水印,可以支持自定义版本:限定宽度,高度自适应;限定高度,宽度自适应;限定最长边,短边自适应;限定最短边,长边自适 应;限定宽高;等比缩放等多种缩略模式。

  示例:

  原图

  限定宽度(600px),高度自适应

  限定最长边(100px),短边自适应

  当然,通过 Nginx 的 image_filter 也可以实现其中的限宽或限高自适应功能、并缓存在本地,只是功能要少,缺少了又拍云存储的CDN加速功能。

  Nginx image_filter 配置示例:

  [js] view plaincopy在CODE上查看代码片派生到我的代码片

  http

  {

  proxy_cache_path /Data/cache/nginx/app levels=1:2  keys_zone=cache_app:200m inactive=7d max_size=10g;

  upstream view_store_server_pool{

  server 192.168.1.2:80;

  server 192.168.1.3:80;

  }

  server {

  <a href="http://view.store.s135.com" target="_blank"> server_name</a> ;

  access_log  off;

  location / {

  proxy_cache_valid  200 600s;

  expires 600s;

  <a href="http://view_store_server_pool" target="_blank">proxy_pass</a> ;

  }

  location ~ /resize_width/(\d+)/(.*) {

  set $width $1;

  rewrite ^/resize_width/(\d+)/(.*) /$2 break;

  image_filter  resize  $width -;

  image_filter_jpeg_quality  90;

  image_filter_buffer 10m;

  proxy_cache cache_app;

  proxy_cache_valid  200 600s;

  expires 600s;

  <a href="http://view_store_server_pool" target="_blank">proxy_pass</a> ;

  }

  location ~ /resize_height/(\d+)/(.*) {

  set $height $1;

  rewrite ^/resize_height/(\d+)/(.*) /$2 break;

  image_filter  resize  - $height;

  image_filter_jpeg_quality  90;

  image_filter_buffer 10m;

  proxy_cache cache_app;

  proxy_cache_valid  200 600s;

  expires 600s;

  <a href="http://view_store_server_pool" target="_blank">proxy_pass</a>;

  }

  }

  ......

  四、可选的关系型数据库服务(即 MySQL 服务)

  1、资源消耗的大户在于 MySQL,影响整体性能的因素也在于 MySQL。对于创业型团队来说,不要过度依赖 MySQL,不要将高并发业务逻辑都用 MySQL 来处理。在 MySQL 前加个 Memcached 做 SQL 查询缓存,跟 MySQL 的 Query Cache 区别不大,治标不治本,命中率不高,还降低了实时性。现在的移动应用,交互性比较强,实时性要求非常高,Web 时代缓存几分钟的老方法,已经不能适合移动互联网时代的需求。因此,MySQL 只适合存储一些并发查询量不大的核心数据,或作为数据的备份,只写入不查询。我遇到过很多创业团队,用户飞速增长时,最后都是被 MySQL 数据库的性能瓶颈蹩了脚,最后不得不减缓产品功能开发的脚步,来做性能调优,失去了与竞争者、模仿者、山寨大王腾讯的竞争优势。创业团队靠什么和大公司竞 争,靠得就是灵活与速度,跑赢大公司。

  2、在不依赖 MySQL 的条件下,那么,最低配的关系型数据库服务(比如阿里云的最低配内存 240M、磁盘IOPS 150、最大连接数 60,70元/月),就能适合自己的需求了,不然,勉强满足一般业务配置的关系型数据库服务的费用,就得 700~3000 元/月了。

  3、如果不选择购买最低配的关系型数据库服务,也可以在自己 1GB 以上内存的 VPS 上,自己搭建一个 MySQL 数据库,磁盘IOPS、最大连接数、存储空间还不受限制。自己做好 MySQL 的主主、主从同步备份,定时dump备份就可以了。需要注意的是,很多VPS默认没有开启sawp,使用 MySQL 请一定记得开启。下面提供一个 MySQL 5.6 版本适合在 1GB 内存 VPS 上的 my.cnf 配置文件。

  [java] view plaincopy在CODE上查看代码片派生到我的代码片

  [client]

  #password  = [your_password]

  port  = 3306

  socket  = /tmp/mysql.sock

  [mysqld]

  port  = 3306

  socket  = /tmp/mysql.sock

  socket  = /tmp/mysql.sock

  basedir = /usr/local/mysql

  datadir = /data/mysql/data

  log-error = /data/mysql/mysql_error.log

  pid-file = /data/mysql/mysql.pid

  #skip_slave_start

  skip-name-resolve

  back_log = 600

  #skip-networking

  max_connections = 1000

  max_connect_errors = 6000

  open_files_limit = 10240

  table_open_cache = 64

  #external-locking

  max_allowed_packet = 4M

  binlog_cache_size = 1M

  max_heap_table_size = 8M

  read_buffer_size = 2M

  read_rnd_buffer_size = 8M

  sort_buffer_size = 8M

  join_buffer_size = 8M

  thread_cache_size = 24

  thread_concurrency = 24

  query_cache_size = 8M

  query_cache_limit = 2M

  ft_min_word_len = 4

  #memlock

  default-storage-engine = MyISAM

  thread_stack = 192K

  # Set the default transaction isolation level. Levels available are:

  # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE

  transaction_isolation = REPEATABLE-READ

  tmp_table_size = 16M

  log-bin = /data/mysql/binlog/binlog

  binlog_format=mixed

  #log_slave_updates

  # Enable the full query log. Every query (even ones with incorrect

  # syntax) that the server receives will be logged. This is useful for

  # debugging, it is usually disabled in production use.

  #log

  # Print warnings to the error log file.  If you have any problem with

  # MySQL you should enable logging of warnings and examine the error log

  # for possible explanations.

  #log_warnings

  server-id = 1

  relay-log-index = /data/mysql/relaylog/relaylogindex

  relay-log-info-file = /data/mysql/relaylog/relayloginfo

  relay-log = /data/mysql/data/relaylog/relaylog

  expire_logs_days = 30

  key_buffer_size = 4M

  bulk_insert_buffer_size = 4M

  myisam_sort_buffer_size = 8M

  myisam_max_sort_file_size = 10G

  myisam_repair_threads = 1

  myisam_recover

  #skip-innodb

  innodb_additional_mem_pool_size = 16M

  innodb_buffer_pool_size = 16M

  innodb_data_file_path = ibdata1:10M:autoextend

  #innodb_data_home_dir = <directory>

  innodb_write_io_threads = 4

  innodb_read_io_threads = 4

  #innodb_force_recovery=1

  innodb_thread_concurrency = 4

  # If set to 1, InnoDB will flush (fsync) the transaction logs to the

  # disk at each commit, which offers full ACID behavior. If you are

  # willing to compromise this safety, and you are running small

  # transactions, you may set this to 0 or 2 to reduce disk I/O to the

  # logs. Value 0 means that the log is only written to the log file and

  # the log file flushed to disk approximately once per second. Value 2

  # means the log is written to the log file at each commit, but the log

  # file is only flushed to disk approximately once per second.

  innodb_flush_log_at_trx_commit = 1

  #innodb_fast_shutdown

  innodb_log_buffer_size = 2M

  innodb_log_file_size = 32M

  innodb_log_files_in_group = 3

  #innodb_log_group_home_dir

  innodb_max_dirty_pages_pct = 90

  #innodb_flush_method=O_DSYNC

  innodb_lock_wait_timeout = 120

  interactive_timeout = 86400

  wait_timeout = 86400

  [mysqldump]

  quick

  max_allowed_packet = 8M

  [mysql]

  no-auto-rehash

  #safe-updates

  [myisamchk]

  key_buffer_size = 8M

  sort_buffer_size = 8M

  read_buffer = 4M

  write_buffer = 4M

  [mysqlhotcopy]

  interactive-timeout

  [mysqld_safe]

  open-files-limit = 10240

  4、如果说 VPS 云服务是必选项的话,关系型数据库服务则是可选项。

  五、结构化存储 NoSQL 数据库

  1、既然不依赖 MySQL 数据库,那么,对于高并发访问,就需要依赖结构化存储 NoSQL 数据库了。虽然一些云计算服务商,也提供了结构化存储服务,但是,不推荐使用。因为他们使用的都是私有协议,你无法在他们的服务质量、稳定性变差了,价格 变贵了,或出现别的更好服务商时,快捷地迁移数据。数据迁移、代码修改的成本太高,还要收到一些服务商规定的单个键值对数据大小不能超过多少、数据导出单 个文件大小不能超过多少,使用了,就等于被绑架了。当你准备迁移时,发现不能停服务、数据量太大导入导出速度慢、数据一致性问题受影响,你会发现,早知如 此,何必当初。

  2、所以,对于 NoSQL 来说,本着使用软件,而不使用服务的原则。寻找开源、免费、付费 NoSQL 软件,安装在自己的 VPS 上,做到多机备份,要好得多。现在的 NoSQL 已经超越了单纯的 Key-Value,对于 List、结构化存储的支持,已经可以取代 MySQL 的大部分功能。

  3、对于我们团队来说,NoSQL(自行开发的BigSea数据库) 与 MySQL 在业务中的使用比例为 80% 比 20%,MySQL 主要用于给内部编辑、销售人员使用的后台管理系统。而对于APP、网站流量,95% 的数据库访问为 NoSQL,5% 为 MySQL。

  4、如果用 MySQL 数据库,一条联合查询的SQL,也许就可以处理完业务逻辑,但是,遇到大量并发请求,就歇菜了。如果用 NoSQL 数据库,也许需要十次查询,才能处理完同样地业务逻辑,但每次查询都比 MySQL 要快,十次循环NoSQL查询也许比一次MySQL联合查询更快,应对几万次/秒的查询完全没问题。PHP 从 5.3 版本开始,已经可以真正地支持多线程。如果加上PHP多线程,通过十个线程同时查询NoSQL,返回结果汇总输出,速度就要更快了。关于 PHP 多线程的使用,会再写篇文章细说。

  六、防DDOS、CC、Web注入攻击

  1、世界上总会有人看你不爽,于是就想着利用不对称的服务器、带宽资源,DDOS、CC攻击你。在云计算时代之前,小规模的攻击可以依靠 iptable,大规模的攻击只能依靠昂贵的专业防火墙了。在云计算时代,可以使用一些专业的防DDOS、CC攻击服务商,比如:与腾讯云合作的安全宝、 跟百度合作的加速乐。

  2、使用这类服务,有一点需要注意,对于域名的@记录,CNAME别名记录和MX邮件记录会冲突,如果将@记录由A记录改为CNAME记录,可能会导致该域名下绑定的企业邮箱服务器收不到邮件。





收藏 推荐 打印 | 录入: | 阅读:
相关新闻      
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款