MD5在论坛上、软件发布时经常用，是为了保证文件的正确性，防止一些人盗用程序，加些木马或者篡改版权，设计的一套验证系统。每个文件都可以用MD5验证程序算出一个固定的MD5码来。软件作者往往会事先计算出他的程序的MD5码并帖在网上。因此，在网上看到某个程序下载旁注明了MD5码时，可以把它记下来，下载了这个程序后用MD5验证程序计算你所下载的文件的MD5码，和你之前记下MD5码比较，就知道你下的是不是原版了，如果两者相同，那么你所下载的是原版。如果计算出来的和网上注明的不匹配，那么你下载的这个文件不完整，或是被别人动过手脚。
MD5的全称是Message-Digest Algorithm 5，在90年代初由MIT的计算机科学实验室和RSA Data Security Inc发明，经MD2、MD3和MD4发展而来。 Message-Digest泛指字节串(Message)的Hash变换，就是把一个任意长度的字节串变换成一定长的大整数。请注意我使用了“字节串”而不是“字符串”这个词，是因为这种变换只与字节的值有关，与字符集或编码方式无关。 MD5将任意长度的“字节串”变换成一个128bit的大整数，并且它是一个不可逆的字符串变换算法，换句话说就是，即使你看到源程序和算法描述，也无法将一个MD5的值变换回原始的字符串，从数学原理上说，是因为原始的字符串有无穷多个，这有点象不存在反函数的数学函数。 MD5的典型应用是对一段Message(字节串)产生fingerprint(指纹)，以防止被“篡改”。举个例子，你将一段话写在一个叫 readme.txt文件中，并对这个readme.txt产生一个MD5的值并记录在案，然后你可以传播这个文件给别人，别人如果修改了文件中的任何内容，你对这个文件重新计算MD5时就会发现（两个MD5值不相同）。如果再有一个第三方的认证机构，用MD5还可以防止文件作者的“抵赖”，这就是所谓的数字签名应用。 MD5还广泛用于加密和解密技术上，在很多操作系统中，用户的密码是以MD5值（或类似的其它算法）的方式保存的， 用户Login的时候，系统是把用户输入的密码计算成MD5值，然后再去和系统中保存的MD5值进行比较，而系统并不“知道”用户的密码是什么。

当前，国内各运营商在多个专业领域正不同程度、不同方向地进行云计算环境构建的尝试和实施工作。在这股热潮中，作为电信运营商中重要的支撑体系之一的OSS体系也在努力尝试和推进，以期紧随发展的步伐。
从当前运营商OSS体系来讲，基于客观的历史原因，每个省至少都存在着10余套支撑系统，而这些系统基本属于“烟囱型”的结构，即从服务器、存储、数据库、中间件、应用软件都是独立并完备的，系统间相互孤立分离，并在网络中通过VLAN的划分进行系统间网络隔离。
在这种背景下，业界对于“虚拟化”、“云计算”、“SOA”、“融合重组”的讨论非常热烈——运营商清晰地认识到过去由于受到历史客观原因的限制所采取的分散独立的建设模式已经无法满足未来的发展形势需要。在运营支撑系统不断完善改进的过程中，运营商也就不可避免地要搞清楚这些概念之间的关系，从而形成相对清晰的OSS体系云计算建设规划。
IaaS层亟待实现存储集中化
云计算基本分为IaaS、PaaS、SaaS三层架构，以此分析OSS体系，其要向云计算方向发展，也需要分层、分阶段地进行。IaaS主要包括网络、主机、存储几个方面，这部分实际上也是当前热度最高的环节，这与技术成熟度相关，更与硬件厂商的推动密不可分。
从当前技术发展角度来讲，实际上就是基于x86平台的虚拟化技术的成熟度最高，它在IT基础架构层面大规模地推动了“虚拟化”、“云计算”的实施。而其中的虚拟化可以认为是云计算的一个基础条件，无论是IT基础架构还是上层软件均需要考虑虚拟化技术所带来的变化。
按照以往经验，具体到OSS体系，运营商应当慎重审视如何推动IaaS的建设。按照当前的现状背景来讲，存储设备的集中化应当排在第一位——这部分分散建设的模式使得每套系统中均需要配置中低端的存储设备，而这些设备扩展能力又很有限，且存储对于系统相关性也是最差的，对于软件系统属于透明的存在，所以OSS体系的云计算环境构建，笔者认为，存储集中化应当排在第一位。
一个不争的现实是，OSS体系的核心模块绝大部分是基于UNIX小型机环境来研发，所以不能简单地将应用直接迁移到x86平台上的Windows环境或Linux环境，这其中需要解决非常多的技术问题。另外，对于中高端UNIX主机进行分区使用，从而规避部署大量的中低端UNIX主机，这与x86平台的物理服务器的配置部署原则是有区别的，这主要是由于技术区别而造成的。
当前的云计算环境构建不可避免地采取了“先集中化、再虚拟化”的建设模式，这样对系统运行安全性实际上构成了新的隐患。与传统的所谓“烟囱型”系统的区别在于它将所有的故障隐患也集中化，一旦某设备资源池出现问题，则将不再是影响一套系统，而是影响多套系统。而且OSS体系中存在大量的采用perl、awk等解释性语言编写的脚本程序，这些程序的典型特征就是高CPU负荷、高I/O负荷，这些程序能否适合部署在虚拟化环境中也还需要进一步的技术研究工作。
需要特别注意的就是，网络是云计算环境构建中不容忽视的重要环节。绝大部分的OSS系统均是按照每个系统一个独立VLAN进行建设的，那么在云计算环境中将大幅度增加网络设置的复杂性。而这部分恰恰是在推进虚拟化或云计算过程中最容易被忽视的环节。
PaaS层技术研究重点在ESB
对于PaaS层，当前OSS体系的技术研究的工作基本是集中在ESB方面，而对于如何构建平台层的研究却很少。从当前的发展方向来讲，对于PaaS这层，应当做到尽可能的“业务无关”——并不是与OSS无关，而是与故障监控、性能分析、业务流程等无关。除了ESB外，在PaaS层实际上还可以对数据库进行集中化，从而通过统一的安全策略和参数设置来形成统一的数据库支撑能力。
当前各个系统中数据库访问效率依然是一个非常典型和重要的瓶颈所在，主要原因在于当前各个系统开发商普遍缺乏代码研发人员与DBA密切互动。由此，数据库比较适宜进行适度的集中规划与部署，然后再“按需”分配能力来满足不同系统的使用需求，而这也恰恰符合云计算的理念。
OSS尚无对外服务打算
对于SaaS层来讲，当前运营商的OSS体系还不适用，因为OSS体系并不具备对外提供服务的能力。
OSS体系内的应用层系统和软件，现阶段的任务是追求如何去适应云计算环境，而不是盲目地追求提供对外服务。如果希望能力外暴，这实际上需要大幅加强软件的可配置性和快速响应能力。例如OSS中的监控系统是可以对外提供设备监控能力，但是在能力分离打包、资源模型调整、告警分析接入、监控规则适应等方面还存在反应速度慢的问题，这样实际上就基本无法达到SaaS的要求。而将内部服务作为系统应用则问题不大。这也是后续OSS应用软件需要重点关注的发展问题。
笔者认为，为了更好地可持续发展，OSS体系的应用程序层应当充分重视到SOA的发展，云计算与SOA是相辅相成的，只有软件符合SOA或者向SOA方向发展，才能逐步形成SaaS的能力，否则各个软件系统依然是孤立的系统。
总而言之，当前运营商OSS体系的建设模式决定了其服务对象是企业内部，甚至是部门内部。基于这种认知，我们需要非常慎重地看待“云”的需求，更应当学习“云计算”倡导的技术和理念，而不一定是过分地追求“对外服务”。

山西云计算中心由山西问天科技股份有限公司、北京蓝汛通信技术有限责任公司、中国联通山西分公司共同投资建设。山西云计算中心位于太原高新区，一期总投资30亿元，计划明年3月动工，年底投产。
山西云计算中心建成后，可以提供10万台机架、百万台服务器，可满足城市规划与城市管理、政务信息化服务、高性能计算、电子商务、物联网、数据挖掘、软件服务等多个领域的科技应用需求。 山西云计算中心建成后，将成为我国中部地区最大的云计算中心。云计算中心是指基于云计算系统，对外提供计算资源、存储资源等服务的机构或单位。当前，主要面向大规模科学计算及工程计算应用，并在商业计算、互联网、电子政务、电子商务等领域拥有巨大的发展潜力。云计算中心作为标志性的IT基础设施，在产业集聚、吸引企业、吸引高端人才、促进招商引资、打造产业链方面具有不可替代的作用，将显著提高城市综合竞争力。