一文说通云架构设计

一、什么是云计算
“通过互联网，以编程接口的方式，调度IT资源，按需使用，按量付费”
这句话总结的很好，它体现了云计算的几个特性
互联网的方式，理论上只要我们的设备可以连上互联网，那么我们就可以访问，使用这些云资源
编程接口的方式使云计算的使用可以自动化，流程化，我们的应用可以像使用api接口一样去使用云资源，通过自动化的脚本去开通，释放云资源。
调度IT资源，云计算的本质是IT资源，一台ECS在使用的时候跟传统的服务器一样去使用，原来客户怎么用现在依旧可以怎么使用
按需使用，按量付费，这两句话通常都是在一起的，在云上我们可以根据需要来购买资源，根据使用的数量，时间去付费，会更加灵活。
这是云计算的几大特征，那么这几个特征带来的价值是什么呢？
二、云计算的价值
1.减少固定资产的投入
有人知道云上的付费模型是什么吗？云上的付费模型其实是后付费，所谓包年包月其实周期也不会很长一个月一年，但是传统硬件的采购其实是预付费的模型，必须要为这些固定资产的投入付费，我们原来要建设一个数据中心，要建机房，规划机位，搞机架，弄强弱电，采购服务器，这些都是固定资产，后续我们还要有专人去维护机房，这是一块长期的成本，往往客户会忽略掉这部分，单纯去比较一台ECS和服务器的价格其实ECS没优势，RDS也是，自建的更优惠MYSQL直接免费，但是如果加上后期专人运维机房的费用，时间那云的优势就可以发挥出来，因为这些是云厂商负责的，用户只需要使用就可以了，现在经济形式也不太好，很多公司都想要转型，那固定资产越少的公司转型可以更加快速，因为他没有负担，云上的这种后付费模型可以帮助公司快速的转型，不用被这些固定资产拖累。
2.资源规模庞大
你是怎么理解这句话的，我谈谈我的理解，分为两块，我们都知道经济学上的规模效应，在云上也是一样的，使用的人越多，云资源的定价会越低，成本都被分担出去了嘛，第二块，任何一个人，一家公司不可能会耗干云上的资源，这是云计算的特性，当我们的业务需要扩展资源的时候，我们不用担心我们找不到相应的资源，因为资源是无限，当然这对你而言。所以在我们扩展资源的时候我会更有信心。
3.快速获取
请问购买到启动一台ECS要多久，我相信不会超过5分钟，对这是云计算的另一个价值，就是即开即用的能力，我今天买了RDS，我不需要经过复杂的配置，我直接就可以使用了，那么快能带我们什么呢？两个字敏捷。现在都在说敏捷，敏捷最大的特点是什么，一个方案我迅速的执行，小步试错，螺旋式的前进，举个例子，以前银行风险部的老总想到一个业务创新的点子，他找到科技部去申请服务器资源，科技部的老总说等等吧，等两个星期机器买来了就行，结果两个星期后两个老总一起吃饭，说你上次要的机器资源到了，另一个说好，但是我暂时没时间搞了，方案就搁置了，真实的事情，在业务创新的时候最重要最难的那步就是开始做，云计算的快速获取可以让业务创新快速开始，不断试错。
4.引入新的运维方式
今天在云上的运维一定是有别于传统的线下运维，不知道各位有体感了吗？你看现在云平台的对于这些CPU，内存的监控已经做的相当成熟了，你只要去配置一些告警规则对吧，去做一些AUTO SCALING的工作，基础资源的维护工作大部分也是云厂商在做，那我们的运维目标就从基础资源的维护聚焦到应用的运维，做好应用监控，去为业务增效，我可以针对用户的访问进行监控，结合DATAV的大屏进行展示，用报表进行汇总分析，去为业务赋能。第二是运维的手段，还记得我们说云计算的特性是编程接口的方式，所以我们可以用自动化的方式去做云上的运维，让运维人员从低级复杂的运维工作中解放出来去做更有价值的工作，聚焦于业务，所以既是机遇又是挑战
5.无需猜测容量
因为资源规模庞大，快速获取，所以我们不再需要去猜测容量了，我只要根据目前的情况去选择合适的云产品就好了，如果不合适我可以快速的调整，不断试错，也不用担心资源会有限制
6.在不同的地理位置经营
今天一个老板说这套系统不错，我想在新加坡部署一套，以前在传统机房时代这是非常困难的，至少我要去新加坡跑一趟看看机房，接触运营商等等，现在在云上，我通过一些自动化脚本我可以迅速的在新加坡部署一套，这个过程非常轻松，所以阿里云有句话让天下没有难做的生意，这是云计算的魅力。
三、企业上云的诉求
Gartner统计的数据显示，企业在上云的过程当中关注的点有以下几个：
1、性能 满足我业务需求即可，客户总是希望性能最高以便于应对突发性的流量洪峰，但在云计算的时代，性能适用就好了，我们有很多AUTO scaling的能力可以应对
2、成本 在满足性能，安全性，可靠性的前提下这套架构方案成本应该是最低的，所以成本不是第一约束，它是附加约束，满足需求即可，如果我们什么都要最好，那成本会控制不住。
3、安全性 在云上我们需要成体系的建设我们的安全防护，基础设施的安全，访问安全，网络安全，存储安全等等，但这也是有要求的，后面会说为什么说安全的建设是有要求的
4、可用性 就是当灾难发生的时候，业务的连续性的一个要求，当然，这个可用性应该是根据业务的特性来，如果说我就是一个官网的介绍网站，那停了就停了，影响没那么大，但是我如果是一个OLTP的网站或者系统，停了影响巨大，那对于业务连续性的要求就会很高，有的甚至要求不停机，那其实就是我们RTO=0了嘛，那可能就用到双活这类的技术去实现，一切都是在满足业务需求的情况下去保证可用性
我们要理性地看待企业上云地诉求，一切都是在满足业务需求地情况下，有侧重地实现，那我们根据企业上云诉求整理出来架构设计地五大支柱。
四、架构设计的五大支柱
体系安全
成本合理
架构可靠
性能适用
高效运维
要成体系地建设我们云上地安全，成本应该是在满足这些需求地情况下是最优地，架构设计地时候要考虑到灾难地发生，保证业务地连续性，性能记住我们这里是适用，而不是极致，由于云计算地出现，现在运维其实已经提前了，前面说过云计算的价值之一就是引入新地运维方式，那在架构设计地时候要考虑到这套方案地可运维性。
下面详细说说这五大支柱
体系安全
想问个问题，谁知道如何评价一个系统是不是安全地？
一个系统安不安全是合规说了算，我们有行业标准，部委标准，甚至于你的公司也可以出一个标准，满足了合规要求，那可以说系统是安全的，合规标准里会对系统的安全项都会提出要求，满足了才能通过，如果说我满足了合规标准，依旧被攻击，只能说这个标准有问题，把制定标准的人拉出来祭天
第二个问题
一个系统安全性是由什么决定的？
是由系统中最不安全的部分决定的，为什么？很简单，木桶效应，一个文件加密了45次，结果传输的过程中是明传输的，前面的工作等于白做，服务器接入了堡垒机，结果所有的对外端口anything全开，这是典型的木桶效应，所以在云上我们要成体系的考虑整体的安全性，而不能单独地考虑某个部分地安全。
Wannacry蠕虫勒索大家知道吗？ok wannacry当时通过感染计算机，将内部文件加密，向企业勒索，你不给还真不行，想要解密就要乖乖给钱，那大家知道wanacry是通过什么端口感染计算机地吗，445
传统地安全防护，大家总是喜欢在DMZ区域做马其顿防线，总是认为威胁是来自于外部地，可是当我绕过你的马其顿防线，就像德军突破法国的防线后一马平川，我在你的内部想干嘛干嘛，今天，云的出现很好的避免这个问题，我们的安全组缺省条件是什么有人知道吗？很重要的一点是入方向是拒绝deny的，应该没人会想起来打开445端口吧，除非是permit any 这个事提醒我们什么？就是要所有层次的实现安全防护，全方位的防护。
有了防护后应该要有对风险评估后的预案，凡事预则立不预则废，等真的出现问题再处理是很慌乱的，有预案可以选择最接近的方案进行处理应急，当然有了预案后还要演练，不实践你不知道你这套预案有用还是没用。
成本合理：
成本往往是我们经常会跟客户直接聊到的话题，那如何做到成本合理呢？
持续地观察评估
我们要让客户知道花了多少钱，持续地观察才能知道怎么去优化，一个8u的cpu 利用率10%，直接降配就可以了成本也就降了
适用托管服务
我们尽可能地推荐客户使用托管式地服务，举个例子rds能做到地是MySQL自建花钱都做不到地，rds自带地高可用架构，自动备份，自动化监控，sql洞察查询一些慢sql 这些实现是要技术地，不是说花钱就可以做到地，谁敢说自己能搭一个10个9 11个9 地存储呢
使用临时资源
我们需要转变思维，从宏观上看云上地资源都是一次性地，需要地时候我临时拓展资源，不需要地时候一脚踢开，直接释放掉，按需使用，按量付费。
多层次地优化成本
这个要从两个角度去理解，一般我们说优化成本，bd给个折扣，给个优惠，按量付费地转包年包月，作为架构师我需要考虑地是从技术地角度去优化成本，客户是医院地影像系统，过往大量地影响资源都是oss标准存储，这些资源一年都访问不了几次，我是不是可以变成冷归档节省费用。一个RDS4个只读实例，我用polardb一定会比rds 4个只读实例省钱，因为polar db 共享存储，所以这是我们架构师需要去考虑地优化成本，多层次地优化成本
架构可靠
一个架构是不是可靠地？
其实是根据业务决定地，前面说的一个官网，停了又怎么样呢？不会造成特别大地影响，但是今天这个系统是一个交易系统，那业务停地时间越久影响越大。，一切都是业务决定的
为了失败设计保持不败
东西都会坏，没有什么东西是不会坏的，我们在做架构设计的时候要考虑到单点故障的问题，能够自恢复，才能保证架构的整体可用性
作为一个架构师，应该要很敏锐的看到哪些地方会有单点故障的隐患，要去避免单点故障的问题
架构中实现松耦合
松耦合很重要，第一部件之间松耦合，不会导致一个部分不可用，而导致其他部件不可用，第二部分自身可以实现不断地迭代，升级，不用整体进行升级，保证系统地稳定性，松耦合后部件自身就可以实现弹性，扩展和缩减。
预测故障的形式准备预案
还是刚刚提到的得有应急得预案，有预案在故障发生得时候可以不慌乱，不然人在紧张得时候会犯错，有了预案要演练，gitlab两个程序员删库的事件大家知道把，两个程序员把库删了，当时他们并不慌，没事我们有5大恢复方案，结果没有一个是起作用的，所以得演练得去实践预案有没有效果。
现在还记得我们的五大支柱是什么吗
安全，成本，可靠，性能，运维
性能适用
我想问个问题，当我们客户或者我们在跟客户聊到性能的时候，这个性能往往指的是什么呢？或者说到底什么是性能
吞吐量？时延？响应时间？都是性能，所以我们在谈性能的时候要具体到刚刚说到的吞吐量，时延上面来，不要用性能这个笼统的词去聊
所以要根据业务的特性去确定性能的指标
了解各种先进技术并合理选择
当我的一个网页查询响应很慢一般有几种选择呢？
1 查询慢SQL，优化sql对不对
2 加索引
3 分库分表
4 读写分离
5 加缓存，寻找热点数据 利用缓存 从架构上开始优化
6 加配置 系统实现弹性 其实就是加配置，一台变2台，这是我最后的手段。他只能增加吞吐量，单个链路处理的时延他是没办法缩短的。
所以性能适用就可以根据业务的特性来决定，没必要做到极致。
高效运维
做好监控对系统了如指掌
系统能访问，不代表现在的状态是最佳的，可能cpu的利用率20%不到，该降配降配，也可能再来两个请求，系统就要崩掉，所以要做好监控，用数据说话。
刚刚我们说什么是云计算，有人还记得嘛？对利用编程接口接口的方式调度it资源，那就可以适用自动化的方式对云上资源进行编排，人总是不靠谱的，机器是稳定的，他只会执行你的代码，所以琐碎的工作我们交给机器去做，自动化运维。
更新或替换转变旧思想，有谁知道怎么理解这句话吗？Ok在云上我们没有必要去想着修复一台ECS，云计算的价值是什么，资源规模巨大，快速获取，我们总能以最快的速度得到一台最新的服务器，可能配置更高价格更低。那台ECS不要了吗？就是不要了，还记得我说的吗宏观上看这些资源都是一次性的，我有了新的，旧的就释放掉
减少底层监控聚焦应用。
刚刚说云计算的价值是引入新的运维方式，我们的目标应该转变，一台ECS的cpu，内存，监控重要吗重要，但是是我们运维的重点吗？我认为不再是，这些资源的监控云上已经有很多成熟的方案给我们，帮助我们去监控，那我们的精力就应该聚焦到上层的应用，过去很多人觉得技术部门不是一个生产力的部门，今天在云上运维可以统计用户的访问量形成报表给运营人员进行分析，为业务增效。
以上就是我们的五大支柱
还记得吗 安全，成本，可靠，性能，运维
我们什么时候用呢
架构设计的时候要用
项目验收的时候，可以根据这个架构设计五大支柱，去看是不是都满足了。