云计算学习
1.典型的it系统
- 机房基础建设，包括机房选址、装修、供电、温湿度控制、监控、门禁等。
- 组建计算机网络，包括大楼综合布线、机柜安装、网络设备购买安装和调试。
- 安装存储磁盘柜。
- 购买和配置服务器。注意，还可能是虚拟出来的服务器。
- 安装操作系统。
- 安装数据库。
- 安装各种中间件和运行库。
- 安装各种应用软件。
- 导入公司的初始化业务数据。
运行库：运行库是程序在运行时所需要的库文件，运行库中一般包括编程时常用的函数，如字符串操作、文件操作、界面等内容，打比方说的话，运行库就是有点像电工人员的工具袋，里面有螺丝刀、电笔、老虎钳、剥线钳
中间件：一是指处于操作系统和应用软件之间；二是指介于应用软件与应用软件之间，目的是为了隐藏差异，以便共享资源和通信。中间件有点类似于电源插座面板，不管插座里面是什么构造，面板上的插接孔都是一样的，这样插座面板一方面隐藏了插座内部结构，另一方面能接插所有的电源插头。
数据库：存储数据的地方
it系统的逻辑四层分布
2.云计算概念
云计算就是一种全新的能让人们方便、快捷的自助使用远程计算资源的模式
一般来说云终端和云端之间是标准的c/s模式（即server/client模式）
云计算可视化模型为下图
云计算的5大特性
1）自助服务
消费者不需要或很少需要云服务提供商的协助，就可以单方面按需获取云端的计算资源。
2）广泛的网络访问
消费者可以随时随地使用任何云终端设备接入网络并使用云端的计算资源。常见的云终端设备包括手机、平板、笔记本电脑、PDA 掌上电脑和台式机等。
3）资源池化
云端计算资源需要被池化，以便通过多租户形式共享给多个消费者，也只有池化才能根据消费者的需求动态分配或再分配各种物理的和虚拟的资源。消费者通常不知道自己正在使用的计算资源的确切位置，但是在自助申请时允许指定大概的区域范围（比如在哪个国家、哪个省或者哪个数据中心）。
4）快速弹性
消费者能方便、快捷地按需获取和释放计算资源，也就是说，需要时能快速获取资源从而扩展计算能力，不需要时能迅速释放资源以便降低计算能力，从而减少资源的使用费用。对于消费者来说，云端的计算资源是无限的，可以随时申请并获取任何数量的计算资源。
但是我们一定要消除一个误解，那就是一个实际的云计算系统不一定是投资巨大的工程，也不一定要购买成千上万台计算机，也不一定具备超大规模的运算能力。其实一台计算机就可以组建一个最小的云端，云端建设方案务必采用可伸缩性策略，刚开始时采用几台计算机，然后根据用户数量规模来增减计算资源。
5）计费服务
消费者使用云端计算资源是要付费的，付费的计量方法有很多，比如根据某类资源（如存储、CPU、内存、网络带宽等）的使用量和时间长短计费，也可以按照每使用一次来计费。但不管如何计费，对消费者来说，价码要清楚，计量方法要明确，而云服务提供商需要监视和控制资源的使用情况，并及时输出各种资源的使用报表，做到供/需双方费用结算清清楚楚、明明白白。
云计算的三种模式
1.IaaS(基础设施即服务)
想避免与计算机硬件相关的资金成本，优先使用这个
2.PaaS（平台即务）
提供获得软件、工具和公用事业的服务
3.SaaS（软件即服务）
应用程序操作支撑环境
云计算的4种部署模型
1）私有云
云端资源只给一个单位组织内的用户使用，这是私有云的核心特征。而云端的所有权、日常管理和操作的主体到底属于谁并没有严格的规定，可能是本单位，也可能是第三方机构，还可能是二者的联合。云端可能位于本单位内部，也可能托管在其他地方。
2）社区云
云端资源专门给固定的几个单位内的用户使用，而这些单位对云端具有相同的诉求（如安全要求、云端使命、规章制度、合规性要求等）。云端的所有权、日常管理和操作的主体可能是本社区内的一个或多个单位，也可能是社区外的第三方机构，还可能是二者的联合。云端可能部署在本地，也可能部署于他处。
3）公共云
云端资源开放给社会公众使用。云端的所有权、日常管理和操作的主体可以是一个商业组织、学术机构、政府部门或者它们其中的几个联合。云端可能部署在本地，也可能部署于其他地方，比如中山市民公共云的云端可能就建在中山，也可能建在深圳。
4）混合云
混合云由两个或两个以上不同类型的云（私有云、社区云、公共云）组成，它们各自独立，但用标准的或专有的技术将它们组合起来，而这些技术能实现云之间的数据和应用程序的平滑流转。由多个相同类型的云组合在一起属于多云的范畴。
比如两个私有云组合在一起，混合云属于多云的一种。由私有云和公共云构成的混合云是目前最流行的——当私有云资源短暂性需求过大（称为云爆发，Cloud Bursting）时，自动租赁公共云资源来平抑私有云资源的需求峰值。
例如，网店在节假日期间点击量巨大，这时就会临时使用公共云资源来应急。
云计算的精髓就是把有形的产品（网络设备、服务器、存储设备、各种软件等）转化为服务产品，并通过网络让人们远距离在线使用，使产品的所有权与使用权分离。
3.云计算的优势和劣势
云计算的优势
1. 对于社会
1）降低全社会的IT能耗，减少排放，真正做到“绿色计算”。
2）提高全社会的IT设备使用率，并降低电子产品的数量，从而减少因设备淘汰而产生的电子产品垃圾，对于保护环境大有裨益。
3）信息技术产业进一步合理分工——由资金雄厚、技术过硬、专业人士众多的机构负责建设并管理云端，从而提高了整个社会信息技术处理环境的可靠性。换言之，也就降低了因天灾人祸导致的生命财产损失。
4）形成新的云计算产业。
5）有利于全社会共享数据信息，打破信息孤岛。尤其是涉及公民的身份信息、档案信息、信用信息、健康信息及教育工作信息等的全国性公共云平台，带来的社会效益更是巨大的。
2. 对于云计算消费者
1）降低了信息技术成本：前期投入和日常使用成本得到大幅度降低，同时也降低了因各种IT事故导致的损失。
2）提高了数据的安全性，具体介绍见后续章节。
3）提高了应用系统的可靠性，具体介绍见后续章节。
4）提高了用户体验：当今网络无处不在，云计算消费者可以随时随地采用任何云终端接入云端并使用云中的计算资源，真正实现移动办公。
5）大型昂贵软件平民化：诸如可靠性工程软件、ERP 系统、CRM 系统、商业智能系统等云化之后以 SaaS 模式出租，这些以前只有大型企业使用的软件系统，现在广大中小型企业和个人都能用得起。
6）从复杂的 IT 技术泥潭中摆脱出来，专注于自己的核心业务和市场。
7）能快速响应消费者对计算资源的弹性需求，从而能及时满足企业的业务变化。在传统 IT 系统下，一项新业务对 IT 资源的扩容要求，往往在数月或者一年后才能得到满足，这使得市场人员和管理层往往难以接受，因为市场是瞬息万变的。
8）有利于企业之间或者个人之间共享信息，打破信息孤岛。
9）个人、中小企业和机构也用得起高性能计算。
云计算的劣势
1）严重依赖网络。
没有网络的地方，或者网络不稳定的地方，消费者可能根本无法使用云服务或用户体验很差。但这并不是云计算固有的缺陷，随着网络普及越来越广、网速越来越快，甚至是城市无线 Wi-Fi 全覆盖、国家无线 Wi-Fi 全覆盖的到来，将使网络不再是问题。
针对这个问题，现在有一些胖云终端产品，它会把一些常见的应用程序驻留在本地，同时缓存数据，当网络良好时，数据自动与云端同步。
2）数据可能泄密的环节增多。
云端、灾备中心、离线备份介质、网络、云终端、账号和密码，这些都有可能成为信息的泄密点。但是云计算使得数据信息遭到非人为因素破坏的概率大大降低了，比如在传统IT系统中，存储设备损坏、机房火灾、地震、雷劈、洪水等都会破坏数据，而在云计算环境则没有这些隐患。总之，云计算消除了一些数据泄密和破坏点，但是又带来了一些新的不安全因素。
3）相对于传统的分散计算，云计算把计算资源集中在一起，因而风险也被集中在一起。
云端成了单点故障，如果云端发生事故，则影响面将非常巨大。目前常见的应对措施是数据冗余存储、建立灾备中心、建立双活数据中心等。
4）用户对数据和技术的掌控灵活度下降。
对于 IaaS 云服务，用户无法掌控基础设施层；对于 PaaS 云服务，用户无法掌控基础设施层和平台软件层；而对于 SaaS 云服务，用户失去了基础设施层、平台软件层和应用软件层的掌控。
另外，数据存放在云端，如果数据量巨大，那么用户移动数据耗时又耗力，如果网速慢，则势必会严重影响数据的掌控灵活性。不过，对技术掌控降低反过来表示用户可以脱离繁杂的技术陷阱，从而专心关注企业的核心业务和市场，因此这也是优势。
4.云架构
美国国家标准与技术研究所（NIST）定义的通用云计算架构参考模型
云服务提供商
云服务提供商的五大任务包括服务部署、服务编排、云服务管理、安全保障和隐私保护
服务编排的中间层的主要功能是把物理资源池化并有效管理被池化后的资源
云服务审计员
云计算审计员能对云计算利益相关者开展独立检查并发布评估结果，审计的核心任务就是通过对客观证据的审查来评估是否符合预设的标准。针对云服务提供商的审计主要包括安全审计、隐私保护审计和性能审计等。
1）安全审计
云计算审计员评估云服务提供商是否具备足够的且准备妥当的安全控制措施以及是否严格遵守切实可行的安全流程。例如，云计算审计员审查云服务提供商是否遵守了 ISO 27001 安全标准。
2）隐私保护审计
隐私保护审计主要检查云服务提供商是否保护了个人信息（PI）和个人身份信息（PII）。
3）性能审计
云服务提供商必须满足在服务水平协议（SLA）中列举的服务质量（QoS）的要求，但是云服务消费者往往抱怨其利益受到损害，而云服务提供商也常常表示无辜，只有通过第三方独立开展性能审计才能消除供/需双方的分歧。
5.云组件
一个IaaS云计算系统包含以下三部分
1）虚拟化平台（硬件、虚拟软件）——解决如何运行虚拟机的问题。
2）管理工具——解决如何管理大量虚拟机的问题，包括创建、启动、停止、备份、迁移虚拟机，以及计算资源的管理和分配。
3）交付部分——解决如何让远端的用户使用虚拟机的问题。
需要注意的是虚拟化中的docker
中间件中的LVS的HA的原理
| 名称 | 作用 |
|---|---|
| Heartbeat | 负责维护集群中各节点的信息及它们之间的心跳通信。 |
| Pacemaker | 集群资源管理器，是核心组件，客户端通过 Pacemaker 来配置、管理并监控整个集群。此组件的社区网站为 http：//clusterlabs.org/。OpenStack 高可用性部署实例中一般都采用 Pacemaker 和 HAProxy。 |
| Resource Agent | 为用于控制服务启停、监控服务状态的脚本集合，本地资源管理器（LRM）调用这些脚本来启动、停止、监控各种集群资源。 |
| Cluster Glue | 包含一套函数库和工具，在集群栈中，除集群消息传输（由 Heartbeat 承担）、集群资源管理（由 Pacemaker 承担）和资源代理（由 Resource Agent 承担）功能外，其他功能都由 Cluster Glue 来完成。它包含的两个主要部分是 LRM 和 Stonith，前者是本地资源管理器，后者的任务是隔离故障机器。 |
如何判断一个服务器主机是否宕机？
通过心跳信号（Heartbeat）检测故障，一台好的计算机会不断向其他计算机发送心跳信号，也会接收其他计算机发送过来的心跳信息。当在规定的时间内没有收到对方计算机的心跳信号时，就启动应急预案，进一步确认故障并准备接管那台计算机的任务。
6.云技术
云布局
目前云化实时强交互性软件的途径有两条：
- 采用网页浏览器（可参考《什么是软件》教程）。
- 在人口密集区建立云端分部，从而降低网络延时。
对于一个服务全国的公共云端来说，一个不错的布局方案如下：
- 在北京、上海和广州三地建设存储云，专门存储租户数据，这三个存储云互为备份，以确保数据万无一失。
- 在省会城市分别建设一个中等规模的云端分部，这些云端分部的主要作用是计算，而不是保存数据，数据被保存到存储云。
- 在地级市建设小型云端支部，完成辖区内的计算任务。
- 如有必要，在县级市建设微型云端。
这些云端是各自独立的，没有从属关系，但是它们都与存储云建立联系。在租户登录时，会自动引导其进入最“近”的云端。比如，租户甲平时都在中山，自然是登录中山的云端，当他出差去北京时，就登录到北京的云端。公共云全国布局的示意图如图 2 所示。
以上原则为"让计算离用户最近"，还有一些其他的原则，比如
"让内容离用户最近"：全称为Content Delivery Network，简称cdn，用户就近访问网络内容，好处如下，一是用户体验好，二是传输成本低
"离能源丰富的地方最近"：能源丰富，电力等会资源就会便宜
"离寒冷的地方最近"：寒冷，意味着能耗可以较低，不用开空调
最理想的建设云端的地区的特点有：寒冷、电力充裕、人口密集、无地质灾害、计算机网络设施发达
存储
外部存储：存储和 CPU 不在同一台计算机上，如 SAN 和 NAS 存储是单独的存储设备，它们通过以太网线或者光纤与计算机连接。专门的存储网络设备很贵，随着以太网速度越来越快，基于以太网的存储技术逐渐流行起来，如 iSCSI，10Gbit/s 的网卡能提供 1GB/s 的理论速度。
注意，这里的单位 Gbit/s 和 GB/s，前者表示每秒多少比特，一个比特就是一位二进制数字，要么是 0，要么是 1；后者表示每秒多少字节，一个字节等于 8 个比特。计算机里的一个字节先要加上一位校验位和一位停止位，然后再通过网卡传递出去，所以一个字节传递到网络上就占据了 10 个比特位。外部存储的示意图如图 2 所示
直接存储：存储直接接插到主板上，通过 PATA、SATA、mSATA、SAS、SCSI 或者 PCI-E 接口总线通信。传统的机械硬盘一般采用 PATA、SATA、SAS、SCSI 接口，相对于外部存储，直接接插主板的机械硬盘的速度优势越来越不明显，但是固态硬盘（如 mSATA、PCI-E）的速度优势还是比较明显的，尤其是 PCI-E 的固态硬盘，代表着业界顶尖的存储技术。直接存储的示意图如图 3 所示。
分布式存储：通过分布式文件系统把各台计算机上的直接存储整合成一个大的存储，对参与存储的每台计算机来说，既有直接存储部分，也有外部存储部分，所以说分布式存储融合了前面两种存储方案。由于需要采用分布式文件系统来整合分散于各台计算机上的直接存储，使之成为单一的名字空间，所以所涉及的技术、概念和架构非常复杂，而且还要消耗额外的计算资源。
IOPS指标：定义为每秒钟能响应的读（或写）操作的次数，体现的是并发性和随机访问能力。IOPS 与磁盘的转速、平均寻道时间密切相关，磁盘的平均寻道时间为 4～12ms，对于转速 7200rpm 的磁盘，我们可以计算出其 IOPS 近似值：1000÷[1000÷（7200÷60）÷2+8]=83。对单块磁盘来说，“读/写”磁盘从微观层面上看是串行的。
那么如何理解主机的IOPS需求转换为磁盘实际IOPS负载呢？
首先我们要明白，主机的 IOPS 需求并不一定等于磁盘实际 IOPS 负载。比如对于 RAID-1，主机写一次，磁盘实际要写两次（镜像的两个磁盘各写一次）；再比如 RAID-5 存储，主机写一次，磁盘要读两次、写两次，共 4 个 IOPS。主机写 1 次对应磁盘实际发生的读写次数称为写惩罚（Write Penalty），阵列类型不同，写惩罚也不同，具体参见图 5。RAID-5写操作示意图如图 6 所示。
图 6 RAID-5 写操作示意图
在图 6 中，主机向 RAID-5 存储写 1001，存储中实际发生的步骤如下。
1）读取原始数据 0110 并与新的数据 1001 做异或操作：0110 xor 1001=1111。
2）读取原有的校验位 0010，并用第一步算出的数值 1111 与原校验位再做一次异或操作：0010 xor 1111=1101。
3）然后将 1001 新数据写入到数据磁盘，将第二步中计算出来的新校验位 1101 写入校验盘。
现在假设主机的 IOPS 需求是 x，读/写比率为 2：1，存储为 RAID-5，那么可以算出磁盘实际的 IOPS 负载 y：
例如 x=360，则计算得出 y=720。假设一个 7200rpm 的 SATA II 硬盘的 IOPS 按 90 算，那么需要
个磁盘，8 个磁盘做成 7+1 RAID-5。在上述公式中，“
”表示每秒磁盘的读次数，“读”不存在惩罚，也就是说，主机的一次读对应磁盘的一次读。
存储的“可用性”指标关乎数据的安全性，是指保存在存储设备上的数据不会丢失的概率。由于磁盘故障而导致用户数据丢失，是一件非常糟糕的事情。通常用几个“9”来衡量可用性，比如 3 个“9”的可用性，意思是一年之中 99.9% 的时间内数据不会丢失。
提高可用性的方法也有很多，比如购买更稳定可靠的磁盘、做成多路镜像、采用不间断电源供电、提高备份的频率，甚至是建立多个异地灾备中心，乃至部署双活中心等。对于当前主流的硬盘产品，我们总结如下，如下表所示。
| 容量 | 带宽 | IOPS | 可用性 | |
|---|---|---|---|---|
| 5400转PATA硬盘 | 128GB~2TB | 1Gbit/s | 30~50 | 如果损坏，还可以恢复大部分数据 |
| 7200转SATA硬盘 | 250GB~3TB | 3Gbit/s | 75~100 | |
| 10000转SATA硬盘 | 300GB~800GB | 3或6Gbit/s | 125~150 | |
| 10000转SAS硬盘 | 100GB~600GB | 140 | ||
| 15000转SAS硬盘 | 100GB~300GB | 3~12Gbit/s | 175~219 | |
| SATA SSD | 8GB~1TB | 3Gbit/s | 400~20000 | 如果损坏，则整块硬盘上的数据全部丢失 |
| SATA SSD | 8GB~1TB | 6Gbit/s | 60000~120000 | |
| mSATASSD | 80GB~1GB | 4~8Gbits | 400~20000 | |
| PCI-E SSD | 60GB~2TB | >8Gbit/s | 12万~1千万 |
注意，表 1 中的带宽单位，Gbit/s 是每秒 G 比特位，MB 是每秒多少兆的字节，一字节等于 8 比特。在带宽的计算中，有经验公式：1B≈10bit，加上了校验位和停止位。比如你家里申请了 4 兆的宽带上网，那么在网络通畅的情况下，下载文件的速度约等于 400KB，即 400KB×10=4MB。
在云端，往往设计两个层次的存储：一个是物理机器访问的存储，一个是虚拟机访问的存储。
容错计算
容错计算，也有人称为高可用性计算和高可靠性计算，就是在系统存在故障的情况下，仍能正确地执行给定的算法。为了实现这一点，必须使系统具有故障检测与诊断、功能切换与系统重组（reconfiguration）、系统恢复与重新运行、系统的重构（reintegration）与可扩展等功能，而且这些功能不能影响系统的正常运行或至少不能使系统的性能下降到不能容忍的程度。
容错计算的重点是保证任务在被处理的过程中不会异常终止，以及任务完成后输出结果的正确性。
接力容错又叫串行容错，由若干台计算机参与同一个任务的计算，但是同一时刻只由一台计算机处理任务，只有当这台计算机出现故障时，才由下一台计算机接力处理；类似，如果此台计算机又出现故障，那么继续由其他计算机接力；只有当全部计算机都出现故障时，任务处理才会被中断，示意图如图 1 所示。
并行容错是指，参与容错的计算机同时处理相同的任务，输出相同的结果。可以在服务器内部的部件层次做并行，也可以在服务器层次做并行，前者主要由服务器生产厂商设计和完成。
现在的绝大多数服务器都或多或少地存在一些并行部件，如双电源供电、多网卡捆绑、RAID 1 支持等。至于在服务器层次做并行，普通民用领域很少采用，多见于航空、军事领域。并行容错的示意图如图 4 所示。
租户隔离
租户行为隔离是指一个租户操作计算机的行为，其他租户感知不到。
租户操作计算机的行为是通过消耗的计算资源（内存、硬盘、CPU 和网络）体现出来的，换句话说，一个租户消耗计算资源的变动不会引起其他租户计算资源的可感知变动，感知不到的变动除外。
例如，租户甲内存配额是 4GB，但是他最多也就使用了 2GB，另外 2GB 空闲。此时如果租户乙运行一个大型软件，消耗了很多内存，使得租户甲只剩下 1GB 的空闲内存，但是租户甲感知不到，因为他的软件运行照样流畅、响应速度照样快、网速不卡，一切如故。
现代很多虚拟机厂商倾向于采用如下的行为隔离原则：按实际使用量分配资源，但不超过租用上限。这里的“上限”是指租户租用的资源额度。
比如租户甲租用的内存额度是 2GB、硬盘额度是 20GB。如果他实际要消耗 1.5GB 的内存，就分配 1.5GB 给他，但是他最多只能用 2GB 的内存。这样，同样的一台服务器就能服务更多的租户。比如一台服务器拥有 64GB的物理内存，假设每个租户租赁 2GB，那么这台服务器很可能允许 45 个用户同时登录。
SaaS、PaaS 和 IaaS 模式都需要实施租户行为隔离。
租户数据隔离
在《云计算SaaS服务模式精讲》教程中，我们提到租户数据包括配置数据和业务数据。配置数据指租户选择的语言、设置的时区、桌面背景图片、屏幕分辨率、创建的快捷方式及各种软件的界面设置等，而业务数据就是日常操作计算机生成的数据，如个人简历、售前 PPT、邮件、音乐、视频、财务数据、库存记录、客户资料等。
租户数据一般保存在家目录或者数据库中，而家目录和数据库被保存在云端的磁盘中。
PaaS 型租户的数据隔离一般采用容器的形式或者操作系统的访问控制列表（ACL），主要在操作系统层设置。而 SaaS 型租户的数据隔离主要在应用软件层及以上展开，租户身份鉴别和权限控制策略由应用软件开发者负责。
比如一个 SaaS 型的 ERP 系统，账号、密码及权限都被登记在数据库中的一个表中，当租户登录 ERP 系统时，输入账号和密码并单击“登录”按钮后，软件要去查询数据库确认账号是否存在；如果存在，再核对密码是否正确；如果密码正确，再根据权限显示相应的模块菜单项。总之，租户的账户信息一定是租户数据记录的主索引的组成部分，这是实现数据隔离的必要条件。
SaaS 型租户数据一般全部保存在数据库中，对于同一个数据库管理系统的租户数据隔离有以下 3 种方法可选：
- 分离数据库。
- 共享数据库但分离 Schema。
- 共享数据库和 Schema。
我们用图 1 来表示一个数据库管理系统、数据库、Schema、Login、User 的关系。
理解了数据库管理系统、数据库、Schema 的关系之后，我们再来看看前面讲的三种分离方法。
1）分离数据库
就是给每个租户单独创建一个数据库，数据库中只有一个 Schema，相当于在大院子里单独建一栋只有一个房间的仓库，仓库钥匙只给此租户一个人。
2）共享数据库但分离 Schema
就是在一个数据库中单独为每个租户创建一个 Schema，相当于在一栋现存的仓库里隔一个房间出来并分配给租户，房间钥匙只给其一人。
3）共享数据库和 Schema
直接给租户分配一个现存的 Schema，大家共享一个 Schema，即租户的数据保存在相同的表中，相当于配一把房间的钥匙给新来的租户，大家共用一个房间，每个人的物品上写上自己的名字，以免拿错东西。
上面三种方法中，分离数据库的隔离效果最好，但是成本也最高；共享数据库和 Schema 的隔离效果最差，但是成本也最低；共享数据库但分离 Schema 是一个折中的方法。可根据租户的需求确定具体采用哪种方法。
下面以云化的一个大型软件为例，来简单介绍一下 SaaS 型租户的数据隔离策略。
该软件原来是落地运行的，主要用于企业产品质量保证，由于价格昂贵，很难推广到广大的中小型企业，所以考虑云化，然后以 SaaS 形式出租。在云化方案中，关于租户数据隔离部分设计如下。
采取“独立数据库、共享 Schema”的混合方法，即每个行业对应一个独立数据库，同一个行业内的租户共享 Schema，如图 2 所示。
图 2 混合数据隔离方法
混合数据隔离方法具有如下好处：
- 方便针对各个行业的特点做定制化。
- 一方面避免表记录数过于庞大，另一方面避免数据库连接成为瓶颈。
- 便于以后扩展（增加新的行业）。
- 便于做数据挖掘和商业智能分析。
每个数据库中包含两类数据：
1）共享数据
共享数据即全部租户共享使用，如基础数据、全局参数、模型数据等，共享数据表不用改动。
2）业务数据
这类数据与租户关联，不同租户的业务数据是不同的，由于租户的业务数据是共享表结构的，所以全部的业务数据表都需要添加一个租户字段 TenantID，且此字段作为主键之一。
同时，还要修改用户登录逻辑，在会话中记录用户所属的租户号和行业数据库，最后需要修改全部的 SQL 语句和存储过程，在 where 子句中都要加上“TenantID=xxx”过滤条件，其中“xxx”是具体的租户 ID 号。
如果出现下面的情况，则表明没有隔离：
- 能看到其他租户运行的软件。
- 能看到其他租户保存在磁盘上的文件。
- 当其他租户运行大型软件时，能感觉到计算机很卡。
- 当其他租户使用迅雷下载电影时，自己打开网页的速度很慢。
IaaS 云服务（包括裸机、虚拟机和容器），平台软件层及以上都是由租户自己安装和管理的，所以 IaaS 云服务天生就具备了很好的隔离效果。
我们在搭建 PaaS、SaaS 云服务时，就要考虑租户隔离问题了，目前没有统一的隔离方法，需要根据租户的需求和性质综合考虑。但是租户隔离不是必需的，比如私有云可以不隔离，因为租户之间互相认识，或亲属，或同事，对于不应公开的资料，自己加密保存或者存储在 U 盘上，此方法既方便又可靠，且节约成本。
对于租户需要输入账号和密码才能登录的公共云服务，必须施行租户隔离。
统一身份认证
一身份认证与单点登录是同一个概念。如果没有统一身份认证，那么你进入任何一个应用系统都要求输入账号和密码，这样一方面难以记住众多的账号和密码，另一方面使用云端资源很烦琐。
对于云端应用系统的访问控制，通常分为三个层面：
- 认证：解决能否进入的问题。
- 授权：解决进入后能做什么的问题。
- 记账：解决做了事情后就要承担相应责任的问题，可能还要付费。
这就是通常所说的 3A 安全机制（Authentication，Authorization，Accountability）。基于 3A 安全机制的访问控制在现代操作系统中被普遍采用，例如 Linux 操作系统访问控制步骤如下：
1）用户输入账号和密码企图登录系统，此时操作系统会进行认证（Authentication），即核对输入的账号和密码与保存在系统里的账号和密码是否相符。如果相符，则允许登录。
2）登录后的用户并不能为所欲为，其每一步操作都必须被授权（Authorization），比如允许进入什么目录、哪些文件允许读、哪些文件允许写、哪些文件允许删除等，都处于操作系统严密的监视之下。
3）用户的全部操作都被作为日志记录下来（Accountability），方便以后落实责任、事后监督，并作为付费的依据。
Windows 操作系统也采用相同的方法。
作为云端的统一身份认证系统，必须实现以下四个功能：
1）统一用户管理（Identification）
租户的账号、密码等信息集中存储，统一管理。
2）身份鉴别（Authentication）
当租户企图登录某个应用系统时，验证他的票据或者身份是否合法。
3）权限控制（Authorization）
规定允许登录系统的租户具备哪些操作权限。
4）操作日志登记（Accountability）
记录租户的操作行为，以便事后责任追溯。
有了统一身份认证，租户登录云端并访问应用系统的过程如图 1 所示。
图 1 租户登录云端并访问应用系统的过程
租户甲首次登录云端的应用系统 5（第 1 步），但被告知要先去统一认证中心获取票据（第 2 步），拿到票据之后返回并访问应用系统 5（第 3 步），然后凭票据直接访问应用系统 3（第 4 步）、应用系统 2（第 5 步）、应用系统 1（第 6 步）。
租户在访问每个应用系统时，应用系统都会查验他的票据，只有票据合法才被允许进入。应用系统在查验票据时都会与统一认证中心确认，不过这一切都是自动的，租户自己感觉不到，但当租户企图访问没有被授权的应用系统时，就会被告知“没有权限”。
不管租户最先访问哪个应用系统，只要租户没有票据或者出示的票据已经过期，都会引导其先去统一认证中心获取票据。但需要注意的是，对租户来说，获取票据的动作只是在屏幕上输入账号和密码，账号和密码的验证、票据的发放等操作都在云端后台自动完成，此后该租户再访问其他应用系统时，就不会在屏幕上显示输入账号和密码的登录画面，因为云端后台自动帮他出示了合法的票据。
SOA
SOA 是面向服务的架构，即企业的 IT 系统是由服务组成的，也即企业的各个应用系统是由许多标准的服务件“组装”起来的，组成应用系统中的各个服务之间是一种非常松耦合的关系。
服务与模块的主要区别在于：模块相当于汽车发动机的零配件，而服务就相当于发动机本身，发动机可以独立运转，而零件就不行。
服务是无状态的，即服务在被调用前后本身没有变化，且同一个服务允许同时在多台计算机上运行，这样就能轻松实现高可用性计算及负载均衡集群，示意图如图 1 所示。
“拆分”工作是实施 SOA 成功与否的关键，拆分视角、拆分原则和拆分粒度（服务标准件的大小）必须事先科学规划。最小的拆分粒度就是一个服务对应某种编程语言的一条语句，这时“组装”软件系统就是传统的软件开发，由软件开发工程师来完成；最大的拆分粒度就是一个应用系统对应一个服务，这时“组装”软件系统就是安装一个应用软件系统，由系统管理员来完成。
科学的拆分粒度介于这两种拆分粒度之间，拆分出来的服务标准件既具备一定的可重用性，又能大大简化“组装”程序的复杂性。通行的做法是，先在软件系统的传统“三层”分层结构的基础上，纵向划分出更多的层次，然后对每一层结合企业的业务特点横向划分出多个“块”，每个“块”完成少量的业务逻辑，这样的“块”就是一个服务标准件。拆分的过程是一个不断进化的动态过程，也是一个由粗粒度到细粒度不断演化的过程。
软件的三层
微服务（鸿蒙ppt里面有说这个？？）
微服务是 SOA 的一个简化版本，并且是具体的实现技术，采用容器对服务打包，可以这样说，如果没有容器技术，微服务就发展不起来。我们都知道，传统的单体应用程序会随着功能的扩展变得越来越庞大，最后修改代码、版本升级或者重新部署都会变得异常困难，甚至根本无法进行。
微服务的出现就是用来解决这个问题的——把一个庞大的单体应用横向切割成若干个微服务，每个微服务只做一件事，但它仍然包含展现层、应用层和数据层。微服务单独运行，对外暴露 API 接口供其他程序调用。所以说，微服务侧重于替换企业内部的大型单体应用，以便于应用程序的可持续演进（持续代码完善、持续版本升级、持续缩放部署、DevOps）。
由于每个微服务都有自己的数据层，所以这个带有状态的微服务就很难跨应用调用。由于每个微服务只做一件事，所以复杂度大大降低；另外，微服务可以单独开发和部署；再者，微服务可以单独缩放扩容，这些都是优点。
但是微服务也存在不足之处：微服务之间的调用关系更复杂，数据一致性保证更复杂，总体微服务部署更复杂。一个典型的基于微服务的应用部署包括若干个微服务实例、API 网关、微服务注册机构及若干负载均衡器等。
通信协议总结
综上所述，在局域网内做比较，从用户体验方面来看：RGS 最好，PcoIP 协议要优于 HDX 协议，HDX 协议又优于 RDP 8.0（Ericom 公司改进了 RDP 8.0，并且终端可以直接采用浏览器），但是 RDP 10 有了很大改进，RDP 10 要好于 SPICE 协议，X 协议和 RFB 协议似乎垫后。
从架构复杂性方面来看：
- 采用 RDP 组建的云计算系统最简化，产品单一、软件许可证单一，小到一台计算机即可做云端，甚至可做服务全球的云端。
- 采用 LTSP 开源项目搭建简单云端比较容易，而且全部是开源软件，但是缺少 Windows 上一些流行的应用软件（如 Photoshop、MicrosoftOffice 等），如果做类似 iPad 的深度定制化，则是一个不错的方向，Raspi-LTSP 是一个替代项目。
- 采用 SPICE 协议建设的云端复杂度较高，虽然可以全部采用开源软件，但必须具备一支技术水平相当的建设团队。
- 而采用 HDX 和 PCoIP 协议组建的云计算系统架构复杂，管理也复杂。
全部使用微软产品的应用环境使用 RDP 协议较合适；需要支持多种桌面操作系统的企业会发现 Citrix 的产品更加适合；如果希望通过使用瘦客户端或零客户端设备作为 VDI 解决方案的一部分，那么选择 PCoIP 技术可能更适合；局域网内的富图形处理业务选择 RGS 较明智。
总之，技术变化很快，各种协议都处于快速的发展变化之中，现在比较的结果与数月后的比较结果可能会有所不同，而且还可能有新的协议不断诞生。具备一定技术实力的公司可以在开源协议（SPICE、X、RFB）方面深入发展，并做出全部采用开源软件的云计算方案，这应该具备良好的发展前景。
7.云安全
云安全的理想状态为
- 使用自由
- 计算可用
- 数据不泄密
- 数据一致性
- 计算可用性
云信息架构
同的云服务模式具备不同的云信息架构。无论是私有还是公共 IaaS 云服务模式，通常包括下面的存储。
1）原始块存储
存放数据的物理介质，如磁盘、光盘、磁带等。在一些特定的私有云中，这些物理介质能被直接访问。
2）卷存储
包括被附加到 IaaS 实例的卷（如虚拟硬盘驱动器）。在存储后端，卷通常被打散存储以增强可靠性和安全性。卷不同于磁盘分区，磁盘分区是对一块基本的磁盘进行逻辑划分。
比如从 101 柱面到 10000 柱面划为一个分区，从 10001 至 50000 为另一个分区，因此一个分区的容量不可能超过磁盘的容量。而卷是在整合若干存储介质（如硬盘、分区、U 盘等）的基础上进行逻辑划分，因此一个卷允许跨越多个磁盘。
3）对象存储
通常指文件存储。不像虚拟机硬盘这种块设备，对象存储更像文件共享服务。
4）内容分发网络（CDN）
对象存储中的内容被分发到离用户最近的地方，以便增强终端用户的网络体验。
块存储、卷存储、对象存储和CDN的逻辑关系如图 1 所示。
云信息架构图
数据打散存储
数据打散存储是一种增强数据安全性的技术，它与加密技术不同，通过对数据分片，每个分片以多个副本的形式分散存储在不同的服务器上，以冗余存储换取数据的高可用性和高可靠性。
目前绝大多数云服务提供商都采用了这种方法。例如，一个 500MB 的文件被划分为 5 个片，每片 3 个副本，一共 15 个片，被分散存储在多台服务器上，这样即使部分服务器损坏，文件也仍然不会遭到破坏。当用户读文件时，读取 5 个分片重新“组装”为一个完整的文件。数据打散存储结合加密技术，将会使数据的安全性得到进一步提高。
数据安全生命周期
1）创建
在第一阶段，人们创建结构化或非结构化的数据，如微软办公电子文档、PDF 文件、电子邮件、数据库中记录或者图片文件。通常在此阶段，根据企业的数据安全策略对新产生的数据进行密级分类。
2）存储
一旦创建了一个文件，它就被保存在某个地方。此时，你要确保存储的数据受到保护，同时应用了必要的数据安全控制措施。通过有效保护你的敏感数据，可以减少信息泄露的风险。本阶段通常与创建动作几乎同时发生。
3）使用
一旦一个文件被创建并存储，那么随后可能将被使用。在这个阶段，数据被查看、处理、修改并保存。此时，在使用数据的过程中需要施加安全控制——你要能够监控用户活动并应用安全控制措施，以确保数据不被泄露。
4）共享
数据经常在员工、客户和合作伙伴之间共享，因此必须要持续监控存储中的敏感数据信息。数据在各种公共的和私有的存储、应用程序和操作环境之间移动，并且被各个数据所有者通过不同的设备访问，这些情况可能会发生在数据安全生命周期的任何一个阶段，这就是为什么要在正确的时间引用正确的安全控制的真正原因。
5）归档
数据离开生产活动领域并进入长期离线存储状态。
6）销毁
采用物理或者数字手段永久销毁数据，物理手段如硬盘消磁，数字手段如加密切碎。
数据安全
数据是否完整、数据是否泄密、数据是否一致都属于数据是否安全的范畴。
数据存放在云端比存放在本地更安全，why？
1. 数据完整性方面
云端通过采用服务器集群、异地容灾和容错等技术，可保证数据万无一失，采用数据快照回滚技术，能最大程度降低用户误删数据的损失，所以云端的数据丢失的概率极低；相反，如果数据保存在本地（计算机硬盘、U 盘、光盘、SD 卡、磁带等），这些存储介质都很容易损坏，另外没有任何措施可防止用户误删数据，现在的数据恢复公司业务火爆就充分说明了本地数据丢失的普遍性。
2. 数据泄密方面
使用密码是目前最常用的防止数据泄密的方法，无论是云计算，还是使用本地计算机，都是如此。比如打开计算机，输入账号和密码登录，然后再输入密码登录 QQ、输入密码登录微博、输入密码登录邮箱、输入密码登录云等。另外，也有采用密码加密文档的，如密码保护的 Word 文档、压缩包等。
在当下云计算还不普遍的情况下，因为本地的存储介质（如硬盘、U 盘、SD 卡、手机、光盘等）丢失而导致数据泄密的概率占到 70% 以上，而其他诸如通过网络泄密的概率不到 30%。因此，把数据保存在云端，可以消除因丢失存储介质而泄密的可能性。另外，就算不用云计算，也存在网络泄密的可能性，除非你的计算机不连接网络。
云服务提供商会采取各种防范网络泄密的措施，如防火墙过滤、入侵检测、用户行为异常分析、泄密预测等高精尖技术，个人用户计算机是不可能花费巨资购买这些设备和技术的。
最后，对于一些敏感的数据资料，用户如果实在不放心，还可以先加密，然后再保存到云端，常用的加密工具有 VeraCrypt、AxCrypt、BitLocker、7-Zip 等，也可以对 IaaS 存储产品（如虚拟机硬盘）全部加密处理。
3. 数据一致性方面
数据没有错乱，没有遭到破坏，能正常打开和使用，这一点很关键。用过计算机的人应该都有过这样的经历：不正常关机（如突然停电、不小心按下计算机的电源开关或复位开关等）后重新启动计算机，报告硬盘文件遭到破坏需要修复，好不容易修复并启动完毕，发现之前辛苦几天编辑的 Word 文档打不开了，这就是各种干扰因素破坏了数据的一致性。
放在云端的数据一致性遭到破坏的概率要远远小于本地计算机，原因很简单，云端环境更可靠：机房恒温恒湿、多级电力保障、阵列存储系统、异地灾难备份中心、安全防范措施全面、计算机专业人员维护等，这些措施使得数据不一致的概率几乎为零。
计算可用性
现在一般来说可用性的故障多出自于停电、断网、硬件故障、软件故障，不过现在由云端、网络、终端组成的云计算系统具备极高的可靠性和安全性，计算可用性极高。
互操作性
互操作性是云计算生态系统中各个协同工作的组件应具备的特征，这些组件可能来自各种云端和传统 IT 系统。互操作性使得我们可以随时使用新的或者来自不同云服务提供商的组件来替换已有的组件，而不会中断云中的任务，也不影响数据在不同系统之间进行交换。
单位组织在使用云服务的过程中可能会考虑更换云服务提供商，常见的原因如下：
- 续签合同时，云服务提供商的报价令消费者难以接受。
- 消费者发现有价格更便宜的同类型云服务产品。
- 云服务提供商停止了业务运营。
- 云服务提供商在没有给出合理的数据迁移计划之前，关停了企业正在使用的服务。
- 云服务提供商的服务质量难以令消费者满意，如未能达到服务水平协议（SLA）中规定的一些关键性能指标。
- 云服务供/需双方之间存在商业纠纷。
如果缺少互操作性（与可移植性），就会出现消费者被云服务提供商捆绑的现象，最终会损害消费者的利益。
一个云端互操作性的优劣程度往往取决于该云服务提供商是否使用开放的或者公开发布的架构和标准协议及标准的 API 接口。许多云服务提供商（如 Eucalyptus）喜欢在标准组件的基础上添加非公开的钩子和扩展，以及一些增强功能，显然这些都会降低互操作性与可移植性。
可移植性
可移植性是指能把应用和数据迁移到其他地方而不用理会云服务提供商、平台、操作系统、基础设施、地点、存储、数据格式或者 API 接口如何。
在选择云服务提供商时，可移植性是需要考虑的一个重要方面，因为可移植性既能防止云服务提供商锁定客户，又允许我们把相同的云应用部署到不同的云服务提供商那里，如建设灾备中心、同一应用全球分布式部署等。
如果未能妥善解决云迁移中的可移植性与互操作性，那么可能会无法实现迁移到云计算后的预期效益，并可能导致成本上升或项目延期，这是因为本该避免而未能避免的如下因素：
1）云服务代理商或提供商锁定——一个特定的云解决方案的选择可能会限制以后转移到另一个云服务提供商。
2）处理不兼容和冲突造成服务中断——云服务提供商、云平台和应用的差异可能会引发不兼容性，这种不兼容性会导致应用系统在不同的云基础架构中发生不可预料的故障。
3）不可预料的应用系统重新设计或者业务流程更改——当迁移到一个新的云服务提供商时，可能需要重新审视程序的功能或者要求修改代码，以确保其最初的执行行为。
4）高昂的数据迁移或数据转换成本——由于缺乏互操作性与可移植性，当迁移到新的云服务提供商时，可能会导致计划外的数据变化。
5）数据或应用程序安全的丧失——不同的云服务提供商可能采用不同的安全控制、密钥管理或者数据保护策略，当迁移到一个新的云服务提供商或云平台时，可能会暴露原先未被发现的安全漏洞。
把应用迁移到云端是外包的一种形式，而外包的金科玉律是“了解前期并做好如何退出合同的计划”。因此，可移植性（和在一定程度上互操作性）应该是任何单位组织计划迁入云端时必须考虑的关键标准，同时开发好一个切实可行的退出方案。
实施建议
1. 关于互操作性方面的建议
1）物理计算设备
同一个云服务提供商在不同时期的硬件或者同一时期不同云服务提供商的硬件差别很大，如果直接让消费者访问硬件设备（如物理服务器），则会存在巨大的互操作性鸿沟。建议：
- 尽可能采用虚拟化来屏蔽底层硬件的差异，但是要注意虚拟化并不能屏蔽全部的硬件差异，特别是目前的系统。
- 如果消费者必须要直接访问硬件，那么从一个云服务提供商迁移到另一个云服务提供商时，选择相同或更好的物理硬件和管理安全控制就显得至关重要。
2）物理网络设备
不同的云服务提供商使用的网络设备（包括安全设备）也不尽相同，包括它们的 API 和配置流程也不尽相同。为了保证互操作性，网络硬件设备应该虚拟化，并尽可能使得 API 具备相同的功能。
3）虚拟化
虽然虚拟化有助于消除物理硬件的差异，但是常用的虚拟机管理程序（如 Xen、VMware、KVM 等）之间存在明显的差异。建议：
- 利用开放虚拟化文件格式，如 OVF，以确保互操作性。
- 了解并记录使用了哪些特定的虚拟化扩展钩子（Hook），虽然这些钩子与虚拟化文件格式无关，但是仍然存在这种可能性：在其他虚拟机管理程序中不起作用。
4）框架
不同的平台提供商提供了不同的云应用程序框架，而且这些框架之间确实存在影响互操作性的差异。建议：
- 在迁移到一个新的云服务提供商时，先搞清楚API的不同之处，然后拟定修改应用系统的计划。
- 使用公开发布的API以保证各组件之间具备最佳的互操作性，为了便于迁移应用和数据，有时很有必要变更云服务提供商。
- 云端的应用系统一般通过因特网交互，可能随时发生各种故障（如组件运行失败、网络中断等）。
我们要做的是，确定一个组件发生故障（或反应慢）将如何影响其他组件，而且当一个远程组件出现故障时，要尽量避免可能会破坏系统的数据完整性的状态依赖——依赖另一个组件对数据的修改。
5）存储
数据类型不同对存储的要求也不同，结构化数据通常保存在关系数据库系统中，非结构化数据通常是按照应用程序（如微软的 Word 文字处理程序、Excel 表格程序和 Powerpoint 程序）所要求的格式存放。为了无缝地在不同云服务提供商之间移动数据，建议如下：
- 以一个被广泛接受的可移植的格式存放非结构化数据。
- 评估数据在传输过程中是否需要加密。
- 检查各种兼容的数据库系统，如果需要，再评估不同数据库之间进行数据移植的难易程度。
2. 关于可移植性方面的建议
把应用迁入云端的过程中会遇到很多问题，在可移植性方面的建议如下。
1）服务水平
不同云服务提供商的SLA也不同，所以有必要了解清楚SLA会如何影响你将来更换云服务提供商。
2）不同的架构
云中的应用系统可以驻留在不同的平台架构中。通过了解应用与平台的依赖性，我们就能搞清楚这些（包括API、虚拟机管理程序、应用程序逻辑等）将如何影响可移植性。
3）安全集成
在维护安全性方面，云系统引入了独特的可移植性担忧，具体包括：
- 现在云系统中的所有组件都会使用认证和身份机制，使用诸如SAML这种开放标准的身份机制将有助于提高可移植性，开发遵循SAML协议的内部IAM系统有助于系统将来移植到云中。
- 加密密钥应该托管在本地，并尽可能地在本地维护。
- 元数据是数据信息的一部分，但经常容易被忽视，因为我们在操作文件和文档时不能直接看到元数据。在云端，我们必须重视元数据，因为元数据随着文件一起移动，当移动文件和文件的元数据到一个新的云端时，要确保安全地删除了源文件元数据的全部副本，否则遗留下来的元数据可能会成为一个安全隐患。
用户自由度
互操作性与可移植性都是为了保障用户能自由使用云服务，这里的“自由”体现在以下几方面。
1）用户可以自由地迁入、迁出云计算，不花或者花费很少的时间和金钱成本。
2）用户能自由访问其他云应用：每个云端都是开放的，在这个云端中的用户能访问其他云端中的应用和资料。坚决杜绝运营商出于利益的考量封闭自身的云应用来黏住用户。
3）用户能自由选择云服务提供商：买方能自由选择卖方是完全竞争市场的一个重要特征。为了保证自由度，政府应该努力营造完全自由竞争的云计算市场，坚决打击运营商“捆绑”用户的不正当竞争行为。
4）用户能自由地把应用和数据从一个云服务提供商迁移到另一个云服务提供商：云端保存了用户的资料并安装用户需要的软件，当用户想更换云服务提供商时不应该存在障碍。扫除人为的障碍，杜绝不兼容性。所以，政府应该制定合理的云计算标准，并提供简单易用的迁移工具。
5）云服务提供商能自由选择云组件：云服务提供商搭建云端，涉及很多技术和软/硬件产品，规划之初就要充分考虑伸缩性、开放性、标准性，杜绝被组件产品厂商捆绑。现在的很多云服务提供商热衷于采用开源的软/硬件产品，这是对的。
6）云终端可以自由接入任何云端：一台终端设备成为人们的云计算总出入口。
加密与密钥管理
加密介绍
根据企业的规章制度，某些数据被列为机密并必须要加以保护，当前存储在企业内部的机密数据开始被陆续迁入云端，所以数据保护的力度必须要加大。把机密数据存储在企业的安全边界之外，这增加了数据保护的复杂度，同时也增加了风险系数。
关于云端的数据加密，以下因素必须慎重考虑。
1）不单单在传输过程中需要加密保护，在云端存储和使用数据的过程中也依然需要加密保护。
2）存储在云端并被共享的非结构化数据文件保护方法有以下两种：
- 采用授权服务器进行集中加密；
- 加密直接被嵌入到每个文件当中（分散加密）。
当使用经第一种方法加密的文件时，首先要联系授权服务器进行解密，比如微软的 Word 文字处理软件会自动联系服务器并完成身份验证和解密工作。
3）加/解密的密钥的管理期限就是数据的整个生命周期，在数据被销毁之前如果密钥丢失，则会导致数据无法解密。另外，对于密钥的保护和正当使用，要尽可能避免依赖云服务提供商。
4）保护那些经常被忽视却又包含敏感信息的文件，比如日志文件和元数据如果不加以保护，那么很可能成为数据泄露的途径。
5）云端的加密密钥应具备足够的强度（如 AES-256），且与同一单位组织内部的加密密钥一致。提倡使用开放的且经过验证的加密格式，尽可能避免使用特有的加密格式。
云端数据库加密
数据库本身具有良好的权限管理机制，但是如果有一下三种情况1，就要加密
- 不想让有权限的人（如数据库管理员）看到记录信息。
- 法律规定一些记录必须要加密（如交易记录中的信用卡信息）。
- 数据存储在数据库的一个 Schema 中，但是数据的主人无法控制访问这些数据的账号（比如多人使用的共享账号，每个人都不能随意修改账号密码）。
数据加密是以提高复杂度和降低性能为代价的，下面是一些替代的方法。
1）使用数据库本身的对象安全机制
数据库中的表、视图、存储过程、函数等统称为对象，对这些对象的访问，数据库管理系统本身提供了一套权限管理机制，诸如账号、分组、角色、授权、撤权等。要严格控制那些被授权的账号，确保这些账号只分配给正确的人。
2）存储安全哈希值
只存储数据的哈希值，而不直接存储数据本身。这使得你的应用程序能证明持有正确哈希值的人就是持有正确数据的人，因为数据与哈希值是一一对应关系，即 hash（data）=x，把 x 存储在数据库中，而 data 存储在另外一个私密的地方，从 x 是无法反算出 data 的。
密钥管理
可使用各种方案，自己手机，基于公钥pki的加密方案或许是一个比较好的选择
云服务提供商
现在比较热门的云服务提供商如下
亚马逊AWS：https://amazonaws-china.com/cn/
微软Azure：https://azure.microsoft.com/zh-cn/
谷歌云平台：https://cloud.google.com/ 需要
阿里云：https://www.aliyun.com/
百度云：https://cloud.baidu.com
腾讯云：https://cloud.tencent.com
华为云：https://activity.huaweicloud.com/
京东云：https://www.jdcloud.com
8.云应用
云应用不同于云产品，云产品一般是由软硬件厂商开发和生产出来的，而云应用是由云计算运营商提供的服务，这些运营商需要事先采用云产品搭建云计算中心，然后才能对外提供云计算服务。在云计算产业链上，云产品是云应用的上游产品。
医疗云
医疗云的核心是以全民电子健康档案为基础，建立覆盖医疗卫生体系的信息共享平台，打破各个医疗机构信息孤岛现象，同时围绕居民的健康关怀提供统一的健康业务部署，建立远程医疗系统，尤其使得很多缺医少药的农村受惠，示意图如图 1 所示。
依托医疗云，可以在人口密集居住区增设各种体检自助终端，甚至可以使自助终端进入家庭。建立医疗云利国利民，其重大意义归纳如下。
1）对于国家公共卫生服务管理部门
有利于公共卫生业务联动工作；有利于疾病预防与控制管理；有利于突发公共卫生事件处理；便于开展公共卫生服务；有利于资源整合、减少重复投资，甚至可以把检查检验功能独立开来，专门成立第三方机构；便于实现跨业务、跨系统的数据共享利用。
2）对于医疗卫生服务机构
有利于提高医疗服务的质量；有利于节省患者支出，缓解群众看病贵的问题；便于争抢生命绿色通道的“黄金时间”；有利于充分共享医疗资源；有利于开展远程医疗业务。
3）对于社区卫生服务站
有利于开展“六位一体”业务；有利于开展健康干预跟踪服务。
4）对于个人
能减少重复的检查检验开支；便于“移动”（如转院、跨地区等）治病；通过远程医疗系统便于享受优质的医疗服务；医疗云结合大数据能预测个人疾病，所以能提前预防重大疾病的发生。
公民档案云
我国基于纸质档案和户口的管理体系极其落后，消耗了大量的社会成本。经历过档案调动或户口迁移的人都苦不堪言，长途奔波，数月折腾，费时、费财、费精力。
如果由中央政府牵头建立和运营全国性的公民档案云，全部纸质材料电子化后集中存放在云中，再辅以公民的指纹数据，并给每个公民发放一对独一无二的公/私钥，而且还可以纳入公民和企业的诚信信息、学历资料等。个人和企事业单位通过安装 APP 就能查阅授权的资料。这才是真正的功在当代、利在千秋的工程。有了这个公民档案云后，以下事情将变得异常简单。
- 人口普查。通过简单查询即可按各种口径统计人口信息。
- 档案调动。
- 户口迁移。不过，户口迟早会取消。
- 诚信信息检索。
- 户口注册和注销。
- 简历查阅。
- 公共决策。通过大数据分析，可以为许多公共决策提供依据。
- 电子材料数字签名。利用自己的私钥签名，接收方利用公钥验证，无人能冒充。
- 血型、器官移植匹配。
卫生保健云
不同于医疗云，卫生保健云侧重于个人、家庭、家族的卫生、保健、饮食、作息等信息的收集、存储、加工、咨询及预测等，重在关怀国民的身体状况，覆盖从出生到死亡的全过程。建设主体也是中央政府，为国家层面的民生项目。
鼓励企业开发各种体检和检验终端设备，如智能手环、家庭简易体检仪、小区自助体检亭、老人和小孩定位器、监护仪等。体检终端设备发放到千家万户，实时收集国民的身体状况数据，云端程序 7×24 小时监测这些数据，并及时把分析结果发到国民的云终端设备上。当沉淀大量保健数据后，就可以采用大数据来做各种定性分析，如疾病预测、饮食建议、流行病预测控制等。卫生保健云可与医疗云、公民档案云建立联动。·
云计算的篇章就此结束~