【低功耗架构开发系列】（一）云服务选型
因为个人事忙，所以很久没有动笔。其实笔者很早就已经想好要写一个“低功耗架构开发”系列，立足于极小型团队开发的架构与技术选型、开发技术的。所谓的“极小型团队”的组成大概如下：
- 每个职能最多只有一名人员配备，而且甚至是兼职人员
- 没有考虑产品经理、运营人员
- 没有DBA、运维等角色
- 暂时不纳入测试
为了理解方便，在此我设置一个虚构的团队作为例子，以后的“低功耗架构开发”系列，都用此团队默认作为团队情况。
- Keith：架构师、后端开发，兼DBA与DB维护、运维
- Adolph：兼职APP开发工程师，iOS/Android/微信都做
- Dragoon：兼职前端开发工程师，HTML+CSS开发+Web开发，UI设计也得扛着
Ended，仅此三人，一人全职两人兼职。
笔者个人觉得团队已经很难精简，据自己的从业经验，通常精通架构与后端多种存储的人员很难精通界面开发，尤其是UI设计这一块，即使有技术把Web端和APP端开发出来，很可能仍然需要Dragoon的角色来优化一下UI，不然根本不能看。而且如今iOS开发已经成为标配，作为架构师兼DBA的人员通常擅长用Java，但对于目前仍以Objective-C为主的iOS多半就只能呵呵了，而且iOS开发还得配齐苹果三件套（不考虑黑苹果），一开始先不采购这个吧（假设没有Mac的话），先由拥有苹果三件套的Adolph收钱做事。
既然是“低功耗架构开发系列”，所谓的“低功耗”指的首先是节约企业/甲方的成本为基础的，所以我觉得再加入一个假设比较合理——开发产品的价格。
在此，我采用一线城市地狱价（比地板价还得低18层，真的给这个钱的话，开发人员都得转行了）的价格来计费：
- 每个功能点算200软妹币
- 界面上增删改查算4个功能点
- 单个HTTP Web接口的实现按照复杂度计算：低复杂度150元一个，中等复杂度200元一个，高复杂度300元一个
- 架构设计、基础组件设计不算钱
- 每个页面按照250元，包UI设计和切图，无论APP还是Web
- 不考虑运维成本
- 每次修改需求，功能点在原需求基础上增加，例如“添加用户”这个功能已经做完了，因为业务变化再做一次，那就是第二个功能点，再收一次钱
好，已经讲完了。立刻进入云服务选型。
为什么使用云服务？这些资料网上随便都有，但是为了方便阅读，我摘选了一些原因写在这里，并且自己加工了一下，说明为什么使用云服务。
对于一个企业、一个组织或者个人，想要在互联网上提供软件或服务，首先有哪几种可选型的基础设施。
- 物理服务器
- VPS
- 虚拟主机
- 云服务/云服务器
因为博客编辑表格不太方便，直接就上图了。下表是自行归纳的4种基础设施选型对比：
![]()
以上表格除了要注意起步成本、升级成本、总成本以外，维护成本其实是算人工的，或者需要招聘人员或者外包去做，这都是成本，请注意了。
使用云服务器和VPS还需要考虑操作系统、数据库（指商业授权的）等正版采购成本，或者其他一些工作所需的软件成本。虽说国内的用户都考虑用盗版，但是作为软件业的同行，我首先还是倡导使用正版，毕竟正版受到重视，程序员的价值才能得以体现。
使用物理服务器因为起步成本太高，不建议中小企业在业务刚起步的时候就使用。退出成本也很高，意思是如果业务被砍掉，机房建设和骨干网接入的费用基本上有去无回，剩下的一堆机器不知道是贱价变卖还是怎么处理好。
使用虚拟主机就不说了，建立一个信息孤岛式的单个应用还可以，想要业务集成的话缺乏技术层面的支持。在云服务已经很便宜、起步差价不大并且可以接受的情况下，还是选择云服务好一点。
选用VPS还是选用云服务，这其实算个问题。
因为选用VPS有一定的好处，比如买一个稍微强大一点的VPS，就可以在VPS上面搭建Git或者SVN作为版本管理，或者一个VPS装上MySQL就可以建多个数据库，分开开发/测试/生产库和备份库，并且可以直接搭建NFS暴露文件，例如图片和多媒体文件可以外链到Web页了。甚至可以搭建一套Atlassian的产品——Confluence+JIRA，用来规范管理你的团队（当然按照以上3个人的低功耗团队来说，笔者认为没有必要）。
如果使用云服务，那么首先需要寻找一个代码托管的云服务（SVN或者Git，SVN少一点，Git比较多），例如GitHub、国内的Coding、CSDN Code等，如果是使用私有库（当然了，打算商用的代码还是不开源好一点）当然是需要付费的，而且是根据代码大小和用户付费，特别是根据用户付费，足够多的用户就很贵了。其次外链的图片和多媒体文件建议使用云服务商的块存储，这个需要使用云服务商的SDK或者接口，增加了代码对云服务商的依赖。
其他的区别暂时不展开说。但是有一条我觉得是要优先考虑的，使用VPS必须自行引入运维监控并且自行保证基础设施（包括软硬件）的高可用性，比如网站或者虚机会不会挂掉、挂掉能不能及时知道等。云服务在这方面非常有优势。在团队还是非常小的时候，业务方向甚至都不明确，尤其是不知道盈利模式的情况下，交给云服务商处理是更保险更省成本的方式，集中精力投入业务开发。
好了，我们选择云服务，接下来应该进入真正的干货，就是选择哪个云服务比较靠谱。
云服务真三巨头：亚马逊AWS、Google Cloud、微软Azure
先说一个情况，由于天朝监管需要，云服务想要在墙内畅通无阻，都需要把数据中心建立在国内，配合管理部门的工作。Google Cloud先说，因为众所周知的原因，所以Google目前还没宣布“I am back”，目前也没什么业务是完全没墙的，更别说数据中心建立在国内了，我们的业务以大陆为主的话，请暂时不要考虑。
亚马逊AWS在国内其实已经先于Kindle云服务落地了，但是截止目前国内版还没对个人商用，都是只能企业的名义申请试用，手续稍显繁琐，所以个人开发者也先不要考虑了。
其他国外的巨头例如Rackspace（姑且不论实际上是否把服务建设在AWS和Azure上面）、Heroku等，都没有强大到在国内建数据中心，所以还是上面这句话，我们的业务以大陆为主的话，请暂时不要考虑。
那么讨论一下国内的云计算厂商，姑且不论提供基础设施和计算能力不能等同于云。
阿里云——没什么好说的，首屈一指的云服务商
新浪云——服务以提供PasS为主
百度开放云、腾讯云、京东云、青云、华为云等——相当于年前的阿里云提供的服务 ，基础设施也齐备，某些服务还有些特色
其实笔者没精力对比国内有名气的云服务商，从同行的朋友方面了解，还是阿里云的受众较多，而且自己也是从阿里云入门的，观察阿里云的产品相对较多，那么就从阿里云开始作为选择的对比标杆。
上面讲到云服务真三巨头已经排除了两个了，仅剩国内版Azure可以用来对比。正好笔者正在使用Azure（因为本人号称公司内头号软狗），那么也拿来对比。先给答案，推荐的是使用微软Azure，笔者不否认对Azure有倾向性，但希望从过程上给读者指导。
说起云服务，势必需要先说计费的问题。阿里云对于个人使用非常友好，起步充值的金额可以很低，相反Azure需要每次最少充值1000软妹币，充值门槛稍高。
虚机价格对比，直接上图。
先是阿里云的，以一台阿里云最低配置的服务器为例，华北区年付费：
再来上微软Azure虚拟机。由于虚拟机没法找到跟阿里云配置一样的，所以笔者选择两个配置，平均一下约等于一个上图阿里云虚机，价格也除以二作为估算：
各位看到没有？阿里云是一年租用，价格才几百块钱，微软的服务器除以二之后也要大约200块钱一个月，而且没有10个月算作一年的优惠，换句话说大概虚机需要2400软妹币一年啊，个人用户表示用不起。但是上面笔者圈住了阿里云图上的一个地方，就是网络还没计算在内。这个结论后面再说。
关系型数据库对于现今的软件开发的重要性不需要再多说，所以再对比一下数据库。
还是先上阿里云的最小实例作为标杆：
微软Azure再次找不到完全一样的配置，拉一个MySQL最低配置过来：
大家看到了吗？阿里云的是5GB开头，MySQL on Azure 100GB免费数据库容量，一年只需要800元左右，价格不但降低一半，而且还容量大了不少。
但是微软Azure强大的并不是MySQL，如果有条件的我们还能使用SQL Server，这才是微软真正强大的地方。
阿里云也有SQL Server，不如也上个对比吧。
这里选择Azure最小实例（基本，适合调试用）和稍微大一点（标准，适合商用）的实例一起与上面阿里云对比：
图上清晰可见，微软在鼓励大家使用SQL Server进行调试，毕竟三十多块钱一个月。甚至省点钱用来生产也是可以的，随时可以平滑扩容。即使是生产库跟开发库分开，生产库使用标准实例，250GB容量VS阿里云的10GB容量（暂时没法讨论连接数、并发数和IOPS），从价格上来说微软云完胜。
有一点大家需要注意的是阿里云的数据库仅能内网访问，意思是访问阿里云数据库的程序必须在阿里云ECS虚机上进行访问，据笔者目前所知暂时还没开放公网访问。换句话说开发库就只能手动搭建在阿里云的ECS虚机上或者本机搭建数据库调试了。微软Azure的数据库可以公网访问，Azure的资源默认可以直接访问Azure数据库，只需要勾上一个选项即可。公网使用的是白名单控制，需要把访问的机器加入到Azure控制台的客户端IP里面。这个问题其实不大，除非是手机，否则使用固网的用户的IP在一段时间内都会在一个不太大的IP段内，配置一个IP段作为白名单，用了这个，笔者从来没在本机上装过数据库了。
说到可以公网访问，Azure数据库的费用是需要加上公网访问的输出数据量的。如果是生产线程序也部署在Azure上面，那么生产线的数据输出流量就没有了，开发线的数据输出流量有多少呢？不做压力测试的话估计是很少的。但是还是上个图给大家看看：
假设开发库单月单个数据库10GB的流量，也才六块多，可以忽略了吧。有同学会问网速如何？这个www.azure.cn上没有写，但是据使用和客服的回答，微软的云服务全部走骨干网的，带宽少说20Mb/s，多则100Mb/s，怕是比您家的光纤还快。而且各位先记住，这个网速适用于几乎所有Azure产品，我们后面会回来说这个事情。
先对比一下其他常用存储的价格，因为相比起上面实在没那么重要（虽然也很重要），所以不上图，直接码字了，请见谅。
K-V缓存：
阿里云Redis：1GB年费1350；16GB 21600/年；32GB 43200/年；64GB 86400/年；
AzureRedis：250MB 104.16 * 12月；1GB 260.40 * 12月；26GB 1979.04 * 12月；52GB 3950.64 * 12月；
阿里云Memcached：1GB年费700.80；16GB 11212.80/年；32GB 22425.60/年；64GB 44851.20/年；
K-V缓存结论：入门价格各有优势，往上升级其实费用总体都差不多。大家切记，阿里云还是只能内网访问。
文档型数据库（两者计算方式不对等，笔者尽量保持接近）
阿里云MongoDB：10GB、1核心2G内存一年4094元；100GB、8核16GB一年31090元；
Azure DocumentDB：10GB、1000 RU大约3600元每年；100GB、9800RU一年月36000元；
文档型数据库结论：入门DocumentDB更便宜（可以选择1GB、100RU），但是往上升级价格双方都差不多，Azure DocumentDB升级容量较有优势。还是那句，阿里云MongoDB只能内网访问。
存储
不想上图了，阿里云和Azure双方的都很便宜，双方都能够添加SSD盘挂载到虚拟机里面，Azure在可靠性上面可以选择本地冗余存储 (LRS)、地域冗余存储 (GRS)、读取访问地域冗余存储 (RA-GRS)三种级别，但阿里云的存储也能保证可靠性。
CDN
阿里云只计算流出流量，Azure既算容量也计算流出流量，相对来说有两重收费的嫌疑。结论是阿里云更便宜点，当然CDN其实也贵不到哪里去，需要用到CDN的时候，CDN的费用占设备总费用的比率较小。
下面要介绍的是微软Azure真正有优势的地方。
首先，Azure的强项并非提供IaaS，而是提供PaaS，意思是我们部署到Azure微软其实其实并不建议部署到虚机里面。还记得上面提到虚拟主机的概念吗？虚拟主机内置运行环境，并且是集群的方式、由云服务商保证可用性，挂了自动重启。
微软是保证99.95%以上正常服务时间百分比，一年故障大概在366天 * 24小时 * (1-0.9995）= 4.4个小时，这种可用性应该说够用了，自己的运维团队要能运维到这个地步相当不容易，几次重启物理机就说不定超过这个时间了。
我们来看看Azure China主打的两种云容器——WebApp和Cloud Service的价格：
免费就不用说了，主要是用来开发调试的，凑合一点用来生产其实也没有不可以，只是不能绑定自定义域名，出去的时候网址会带有.chinacloudsites.cn结尾，如果做手机APP或者微信应用的支持，可能问题不大。
“共享”级别的WebApp实例不到82块钱一个月，一年不到1000块钱，用于生产还是可以接受的。
“基本”级别的1G 1.75GB内存价格高一些，一年几千块钱顶住一台虚机了，到底值不值得？下面来看看Azure WebApp真正的杀器。
首先是“出站数据”，从共享实例开始就是没有数据限制的，基本实例也是。每个月100G流量也才67块钱一个月，流量真的不贵，上面我们说过，Azure的网速相当快。而我们上面计算阿里云ECS虚机价格的时候，还没有计算网速和流量呢，现在该来算这笔账了。
好了，我们加上网络流量和把虚机缩放到“基本”小型（S）配置差不多的1核2GB，价格已经开始拉近了，Azure的价格相当于阿里云的一倍。但是Azure提供单个地区（华北和华东两个地区）各10个的免费WebApp实例，用作调试相当不错，这算是大大降低了开发线服务器成本。不过是要充值1000块钱Azure账户处于活动状态的时候才可以使用。
那么免费的Azure实例能够做些什么支援生产线？最主要的是其实是WebJob。WebJob（其实可以放在任何WebApp里面使用）主要是用来跑后台任务的，例如定时任务、监听消息队列触发的任务等。.NET开发的话我们需要用一个NT服务来做，Java开发我们需要写一个控制台程序并且用Shell脚本跑起来，结合Quartz或者用Linux下的crontab来触发等等，都要占用虚拟机资源，并且都需要进行框架性的开发才能在上面开发业务功能。而WebJob不需要，这相当于再次变相降低我们的机器消耗，但在这里不展开WebJob的作用了，在后面的文章会讲到。
上面提过Azure的弹性缩放是支持到计算容器级别的，也就是WebApp也支持。为了全面展示Azure的缩放，直接用了“标准”级别的WebApp说明。
首先缩放是以AppService为粒度的，在后面的文章再展开讲AppService，暂时可以认为一个AppService就是一台虚机，AppService上面可以部署多个WebApp。
上面以AppService一个应用为例，我们看看有哪些缩放选项。
上图是按照CPU缩放，可以设置日程缩放，这对于做促销活动（一定时间内访问人数变多，之后逐渐变少）很有作用。实例计数就是云服务会帮你设置规模调整所允许的的最小和最大虚拟机数，Azure 从不超出或低于这些限制。目标CPU范围表示你的 WebApp的平均 CPU 使用量，如果高于或低于指标Azure将添加或删除标准实例以使你的 Web 应用保持在此范围内。
这个就是大杀器了，我们使用云计算的目的是按需使用，有了以上特性我们完全可以对一个AppService在一定时间升级以支持用户访问，在满足要求之后自动缩放回到便宜的AppService运行状态，不需要运维人员人工干预。
继续说Azure的优势。Azure对WebApp的监控很到位，在Dashboard里面的所有监测功能都免费，不需要自己搭建Zabbix监控了，在此就不截图了，各位可以网上找资料看看。
目前还有上面这图的情况，Azure正式用户每个月前面1TB数据流量免费，超出1TB收费已经在上文讲过了，其实也不贵。所以这样看来是不是
如果日后真的发展为大规模使用，Azure企业账号是16万软妹币起，企业账号在使用Azure资源的时候打73折，再次拉近了Azure与阿里云的价格差距了，而且是全面的73折。
企业用户还有世纪互联很到位的服务，假如部署个Java Web程序到WebApp上面跑不起来，世纪互联的人会帮忙定位是不是web.xml文件写错了之类的问题，这个企业费用相当于是外包了一部分技术问题了，在请个全职人员很贵的情况下相当值得。
总结一下。阿里云为代表的云服务商其实是很注重运维体验的，但是微软的策略并不一样，微软注重的是全开发周期的体验。所以Azure的功能是与Visual Studio集成的。我们如果部署到服务器上面，一般是FTP连接服务器，传输执行文件到服务器之后覆盖到执行目录然后重新启动程序。在Visual Studio上面不需要这样，直接用Visual Studio的Publish to Azure功能，选择从Azure控制台下载的publish配置文件即可，Visual Studio + Azure会自动差异上传文件，而且WebApp不需要重启就能生效。所以自从用了WebApp，笔者已经舍弃了手工部署到服务器好久，而且本机连Web服务器都没有装（数据库肯定也不需要本机的了），直接使用Visual Studio上传到免费WebApp调试，还能使用Visual Studio远程断点调试，觉得自己的电脑真的很干净。
微软也为Azure提供了众多的SDK，大大地简化了开发的工作量，使得上述的3人开发小组能够减轻不少的工作量，所以才能够假设200元左右一个功能点的价格。开发这方面节省的费用远远超过Azure设备费用的付出，后续的文章将一步步讲述。
然后说一个Azure的优势，如果日后真的发展为大规模使用，Azure企业账号是16万软妹币起，企业账号在使用Azure资源的时候打73折，再次拉近了Azure与阿里云的价格差距了，而且是全面的73折。
企业用户还有世纪互联很到位的服务，假如部署个Java Web程序到WebApp上面跑不起来，世纪互联的人会帮忙定位是不是web.xml文件写错了之类的问题，这个企业费用相当于是外包了一部分技术问题了，在请个人很贵的情况下相当值得。