一、 关于云
1. 云产业分析
根据IDC的分析报告，美国和中国云计算产业发展差异巨大：美国以公有云为主，SaaS*大、IaaS*小；而中国截然相反，以私有云为主，IaaS占了大约50%的份额。
究其原因，跟中美两国云计算产业发展的阶段、成熟度有很大关系。
中国的公有云主要使用者是小微、创新企业等。我认为IaaS公有云已经或者将要巨头化，PaaS还有机会，SaaS会是云计算几大分类中的爆发点，但是要看准行业。
在诸多产业中，中国云计算私有云市场主要的客户来自：通讯、金融、政府。金融行业受安全、政策、法规的约束，几乎不会选择公有云，大型国有银行私有云的建设步骤也很谨慎、渐进式，会首先考虑迁移非核心应用；小金融相对对新技术比较开放，会实验一些开源的技术，如Openstack、ceph等。
政府由于“十二五”、“十三五”政策持续推动、对于政务云建设的现实需求、统一纳管基础设施资源、节省成本等考虑，对云计算的投入较大。
2. 国内有私有云需求的四类企业
a) 政策驱动
因为政策持续推动、创新补助、领导要求（政绩）等原因，需要上云的企事业单位、行政机关。
b) 人云亦云
不解释，：）。
c) 新技术跟进
看见新技术的发展、成熟，希望在其中分一杯羹，也包括IDC之类的转型企业。和上一类的区别一个是模糊的、被动的，一个是有自主想法、主动的。
d) 为业务而云
因为业务发展规模（含弹性）、统一上收资源、成本等考虑云。主要也分两类大型互联网企业和传统大型企业。
前者因为业务发展需要考虑云计算，从成本、技术可控性考虑，会采用大量的开源技术，同时会对硬件、软件提出改造要求，大力发展分布式、集群技术以适应其性能、可靠性等需求。典型的代表是阿里等。
而传统大型企业走的是另一条路，相对稳健，会选用成熟可靠的商业化解决方案为主，如虚拟化选择VMWare。另一方面，这类企业相对比较谨慎，会以规划咨询、POC、招标、建设、交付、运维相对固定的模式去建设云。典型的代表是大型央企。
3. IaaS、PaaS、SaaS分析
我把顺序放过来，先说SaaS，再说PaaS，IaaS。
SaaS我认为主要会在三种情况下出现：
a) 行业SaaS
有行业属性的SaaS，如教育、医疗、培训等。
b) 工具化SaaS
比如workday类似的管理工具、office365类似的文档工具等。
c) 大型企业（组织机构）内部SaaS
有些企业内部，各地/部门业务类型相对一致，使用SaaS软件统一上收权限，节省成本等。
如我之前所说，如果找准行业、方向，SaaS可能是创业的大风口。
PaaS的实现我认为有两种：
a) 基于商业化自动部署工具的
大型企业考虑人员技能、维护成本、可靠性等要求，较多选择类似方案。HP、IBM、BMC等都有类似的工具。自行实现的话，可以考虑流程引擎加上脚本执行器再加部署包。
b) 基于开源框架和软件的
选择cloudfundry、openshift框架，加docker等技术，目前随着相关技术的成熟，越来越受到关注。上述的几个大外企实际上也有类似的实现。
IaaS的情况比较复杂，我认为难度主要在理清几个头绪：
a) 业务对于底层资源的要求、约束
联想的架构师团队正在做一件事情，就是梳理业界存在的十几种主要的企业业务架构（如电商、搜索等等），分析和总结它们对于资源的各方面要求，如计算能力、IO等等。
b) 服务的设计、编排
需要从业务的承载要求、客户消费方式、业务系统架构、部署方式、虚拟化方式、集群、资源类型做统一的规划设计。根据对客户现有情况的分析，尤其是IT系统现状、痛点等，得出客户的期望，进而设计出客户需要的服务。
c) 服务与资源的关系
很多人搞不清楚什么是服务，什么是资源，甚至有个号称云架构师的人跟我说，他实习了对虚拟化的纳管、资源调度，就是完整的云。
资源（resource）：在系统中， 基础设施、network设备，VM、host、OS、CPU、Memory、存储、software等等都被视作可分配资源。
服务是云计算的核心特征，根据业务要求等可以编排服务，使之能让客户消费，通常会绑定价格、SLA等一些附带属性。
d) 租户与组织的关系
要想清楚，根据客户现状，组织与租户怎么对应，是1对1，1对多，还是多对多。
e) 资源调度的原则
要考虑资源调度策略、资源类型、性能要求，同时要考虑弹性的时候如何伸缩。经常会有只能scale out，不能scale in，或者频繁scale out、in的情况出现。那么在考虑弹性判断条件、算法的时候，要综合几种监控告警数据，如业务、资源。
二、 IaaS方案
1. IaaS架构影响因素
如我之前在群里所说的，个人认为很多因素都会影响企业IaaS架构的选择，主要有以下一些：
a) 企业IT发展规划
b) 企业组织架构
c) 企业管理制度
d) 业务类型
e) 应用层次
f) 人员技能
g) 技术成熟度
h) 成本
i) 周期
j) 运维体制
k) 。。。
如果不考虑其中的某个因素，都有可能导致项目的失败。我曾经亲身经历过，因为管理和客户组织架构原因导致的云项目失败。客户在实施云计算建设之前，业务部门是强势部门，IT部门是支撑部门，而在规划和建设中忽略了客户组织架构的影响因素。IT部门变成了云平台的管理者，业务部门成为相对弱势的云服务消费者，导致客户内部组织架构重组、项目停滞。
2. 私有云IaaS平台构成
我这里讲的是广义的云平台，我一般认为分成几大部分：门户（管理和自服务）、服务层、统一资源层（含适配器层）、基础设施（含虚拟化），紧密相关的有BSS、OSS子系统；外部可能交互的系统有ITSM、CMDB、外部监控系统、4A系统和通知系统等。我画了一个主要部件的草图，方便大家理解：
a) 门户分为管理和自服务，分别给管理员和普通用户提供服务；用于展示基础设施、平台及软件服务，并控制用户接入方式，对用户的访问范围、界面的展示方式做设定等。以便于管理员和普通用户获取服务的信息，申请并使用各类服务。
b) 服务层指服务构建与设计的逻辑组件，它负责定义服务的结构、流程等信息，组装原子服务，生成业务服务，发布到服务目录，监控服务运行状况等，形成完整的服务生命周期管理。业务用户可以通过服务管理层获取云计算服务；管理员可以通过服务管理层监控所有服务实例的整体状况；服务开发人员可以通过服务管理层定义和发布服务。服务管理层将以业务服务的形式对外发布所有的服务操作接口。
c) 资源层指管理和调度软硬件资源的逻辑组件，它负责构建资源池，生成简单资源供应的技术服务（原子服务），定义资源运维的操作流程。为了组成资源池，一般将同质的设备集中安装，相互连接，并通过一定的管理软件来监管和配置。资源池由同质的一组资源组成，用户可以通过资源管理层软件从资源池中申请资源，指定该资源实例的配置，并管理其运行。管理员可以监控每个资源池的资源使用率，健康状况和性能状况。资源管理层将以技术服务的形式对外发布所有的资源操作接口。这一层要屏蔽掉虚拟化等的差异，使得上层无法感知。
d) 基础设施包括计算、存储、网络，其中计算含各种异构虚拟化。
e) BSS和OSS源自电信行业的B和O，BSS负责营销、结算等功能；OSS负责监控、安全等。不展开了。
3. 虚拟化异构
能否支持X86虚拟化异构、异构的支持广度是衡量一个云资源管理平台（区别与云服务管理平台）的一个重要标准。目前主流的虚拟化软件有几种：
a) Vmware
b) Hyper-v
c) Xen
d) Kvm
e) 在kvm和xen上演化的各种版本
在此不考虑lxc等。
主要的实现思路是在资源层做统一纳管，用一套接口整合，也即适配器模式，每种使用一个适配器。在实际开发中，一般接口做二次抽象。
目前*常见的异构是VMWare和KVM（Openstack纳管），目前有几种途径：
a) 自己实现，调用vcenter或vsphere的接口
推荐使用这种方式。
b) 各企业商业发行版
如，mirantis、hp hellion os商业版、racespace等，基本上不尽成熟，或者高级功能有缺陷。
c) VIO（VMWare Intergrated Openstack）
很多人跟我推荐VIO，我反对，理由有几点：
1. 遗产系统接管。如果对于已有的VMWare虚拟化，VIO无法接管
2. 性能。VIO部署在虚拟机上，作为vcenter插件，性能无法保障。
3. VIO本质上还是Openstack的一个实现，没有高级功能。
4. 如果需要SDN，要集成NSX，成本等各方面都需要考虑。
4. 小机与X86异构
除了X86虚拟化异构，还要考虑小机（主要是IBM power）、物理机、虚拟机的供应，这时也要考虑小机的纳管需求。采用的方式也是在资源层统一纳管，但接口会有独特性，一般用流程引擎调HMC解决。
5. Openstack及其应用场景
Openstack现在持续火热，各大厂商都在积*参与，本人也参加过openstack峰会。结合工作中的实际，我认为Openstack长期来讲是个好东西，适合一定场景的应用范围，但并不普适。可以应用在：
a) 开发测试环境
b) 非关键业务
c) 科研实验环境
我认为Openstack需要解决的问题有：
a) 稳定性
b) 可升级
c) 高级功能，如HA等
d) 遗产接管
此外，我认为Openstack存在贪多求快的问题，面铺的广，不够扎实，主要使用的还是那几个核心模块。
6. SDN不是企业级私有云基本需求
我曾经设计了一个集成SDN和NFV（部分功能，如SLB、VFW等）对的拓扑设计器，但在具体的企业级客户中，并没有太多客户迫切需要SDN。都会提到、以后扩展到SDN的实现，而不是眼前。
我认为SDN主要应用在几个场景：
a) 公有云，租户定义私有网络
b) 私有云，需要频繁变更网络拓扑的环境，如开发测试、科研等
c) 电信、IDC等
7. 云管平台部署架构
云管平台的部署和普通的SaaS网站没有什么不同，都是SLB加HA，后端应用集群、数据库集群，一般没有很大的压力。
三、 云不一定节省成本（我知道我说在这个可能很多同行要扔搬砖，可是作为一个驾狗狮，虽千万人吾往矣。。。）
1. 规划、设计和建设周期长。云平台要承载所有准备上云的业务系统，考虑因素较多，如前述。
2. 前期采购成本高，前期资源池建设采购的设备数量较多，占用大量的机房、电源等资源，投资和运维成本均较高，一定时间内会闲置。前期规划能力不足，也会造成资源浪费。
3. 对企业的组织管理制度可能会有调整、单体人员技能会有较高要求，造成行政和人员成本升高。
4. 管理维护成本高、维护力量无法分层：维护人员要分成不同的团队，分别管理云平台和业务，必须熟悉平台所涉及的所有的软硬件资源，维护效率不高
5. 人云亦云，并不少见，尤其是资源池较小的情况下，纯属浪费。
————————————————
原文链接：https://blog.csdn.net/wx_15323880413/article/details/100516721
