论文部分内容阅读
最近“去IOE”炒得火热，作为一个在中国移动从事IT技术的人，基于中国移动的现状，笔者也发表几句不成熟的想法，请诸位专家批评指正。
“去O”的应用驱动分析
从技术角度，没有什么是绝对不能做的，只是看代价多少，以及是否合适。
比如，当年阿里还没“去IOE”时候，浙江移动某些系统就在用MySQL了。MySQL不是天使，Oracle（甲骨文）也不是妖魔，关键还是要看用户的技术场景和技术管理机制。适合你的，就是好的。
此外，浙江移动2011年的CRM项目，包括我们自己做的一些技术创新，都基本证明了在运营商生态环境下，“去I”和“去E”这两件事情，都没有大的技术难点，难点在于“去O”。
从技术能力储备和管理体系分析方面我们就可以看出一些端倪。像阿里巴巴这样的互联网公司，它们自己掌握开发人员，自己掌握架构，其中又包含了应用架构、技术架构和数据架构。阿里巴巴的技术团队的薪酬管理体系，很能体现技术人员的价值，适合技术人员生存发展。在这种环境下，开源数据库的缺点完全可以靠自己培养的、国内少见的代码级专家来解决，开源数据库与应用可以做到高度融合。
运营商的情况却完全不同。由于开发长期完全外包，自己几乎没有研发技术人员，体制内也缺乏技术人员的发展环境，这导致十多年前培养起来的真正具备动手能力的少量第一代技术骨干，正随着时间流逝风雨飘摇。与此同时，新生力量又顶不上来。现状是，运营商对核心能力的掌控非常有限。相对来说，技术架构的掌控还算得力，但应用架构和数据架构已经成为现实的重灾区。最终，在运营商生态环境中，可以对MySQL进行代码级掌控的元素已基本缺失。
实际上，阿里巴巴做去IOE有其业务发展上的原因。
对于互联网和传统企业来讲，最终都得为用户服务。因此其希望尽量减少收费和依赖，变成一个尽可能廉价且拥有性价比的公共服务平台，在这个平台上则可以产生出更好的服务。而运营商的应用场景目前来看，比较明确的还是私有云，并且希望通过“去O”加强自身核心能力的建设，减少对合作伙伴的依赖，剑指亚联这样的开发商和Oracle这样的平台提供商。
很多人认为，阿里巴巴“去O”的技术原因，是Oracle不能满足互联网业务的可扩展性需求。我觉得这个理论可能是站不住脚的。充分利用闪存混合架构，MySQL的单库容量都能提高，更何况Oracle数据库？而且还有Exadata这样的产品来为Oracle“撑腰”。在海量数据的处理方面，直接用Hadoop、NoSQL就可以，本来就和“去O”这种使用场合的议题扯不到一起。
“去O”的技术难点
“去O”需要考虑以下几个方面的问题。首先是数据一致性。具体操作上，这需要看不同的业务需求，但是运营商的核心系统一般是有强一致性要求的。此外，还要关注复杂查询支持、单机扩展性以及优化的成熟度三个方面。 、
这几个问题，会显著增加业务开发的复杂度， 因为必须将这部分功能的需求，在应用层实现。对于技术储备一般的公司来讲， 这就是非常高的门槛了。而运营商，在这几方面也正好“中枪”。
因为“去O”必须将部分原本已经在数据库层实现很好的功能去掉，交给应用来做，因此这往往会造成开发浪费。对于阿里巴巴这样拥有开发实力的互联网公司来说，从业务角度看是值得投入的，但对运营商来说，完全可能是自找麻烦。
运营商最好的办法，是向互联网公司学习改革，创造机制培养自己技术人员。如果做不到，那在数据库这种核心平台相关的架构上，或许还真不如用那些国际大公司的产品。
从技术生态环境的角度看，不可否认的是，Oracle的数据库产品确实出色，特别是在较为传统的OLTP和OLAP场景下更加如此。事实上，开放和封闭的差别，不仅仅存在于代码环节，还存在于技术支持环节。而在移动环境下，后者比前者更加重要。Oracle数据库有非常开放的技术文档，带来了极度繁荣的、独一无二的第三方技术支持市场。
“去O”不是直接上MySQL，产品的选择不是儿戏，不能简单抄袭。还是那句话，环境不同，别人适合的东西不一定适合自己，反之亦然。此外，选择产品本身也可能涉及到技术路线的选择。MySQL和Oracle相比功能要简单得多，很多复杂查询不支持，数据结构很多需要转换，语法也差别较大。也就是说，如果把程序从Oracle割接到MySQL，数据倒换代价不说，代码基本上兼容性较低，需要重写的部分占比应该会很高。而现实情况是，运营商对业务连续性的要求极高，但技术掌控力又不如互联网企业。这种情况下，想象一下运营商的系统“去O”会面临什么样的挑战？
运营商该如何对待“去O”？
没有金刚钻，别揽瓷器活。“去O”有风险，操作需谨慎。在这个问题上，不能被一些人云山雾罩地一吹就晕，一味照搬互联网公司的做法，简单粗暴地快速全面“去O”，那样很容易搬起石头砸自己的脚。场景不同，还是要实事求是，因地制宜，不能脱离实际。
运营商应该把精力，花在局方和第三方Oracle技术支持力量的培养上。市场上有那么多专业的第三方合作伙伴，全国一盘棋，是否能在技术支援体制上做文章，改变现有的各省“烟囱式”技术团队的现状？运营商内部好的甲乙方技术力量，是否可以复用创造更大的效益？
如果确实要这么干，那么应该从对数据的强一致性、数据库的可扩展性、安全性等要求相对不高的系统入手，逐渐积累经验，锻炼队伍，逐步深入。或许有那么一天，我们能将“去O”落实到我们的核心系统中，但这一天应该不会马上到来。要知道，技术掌控力强于多数运营商的阿里巴巴，目前真正涉及到钱款交易的支付宝核心系统，仍然在使用Oracle。可以看到，互联网公司的“去O”进程，也是由浅入深，由外向内的，这一点值得借鉴。
此外，运营商也可以考虑一下国产数据库，走国产库的路是符合社会特点的。
很多人一谈到国产数据库就嗤之以鼻，笔者认为这种态度不可取。现在国货或许还不行，但我们还是要努力培养，让其尽可能茁壮成长。至少，目前国产数据库与Oracle代码在纸面上的兼容性要强于MySQL，而且不同程度地支持与Oracle的异构容灾。国产数据库发展壮大，我想也不是完全没有可能，没准我们的国产数据库厂家也能成为下一个华为呢？
总之，“去O”数据库产品的选择，本质是在运营商环境下不同技术路线的选择。西药立竿见影，中药固本陪源，归根结底还是要培养自身技术力量，多学习互联网公司以及银行业的先进经验。只要正确理解、有机汲取互联网行业的先进技术思路，结合运营商的现实环境情况，开拓思维，勇于创新，我们一定能走出一条我们自己的有运营商特色的“去O”之路来。
总之，“去O”数据库产品的选择，本质是在运营商环境下不同技术路线的选择。西药立竿见影，中药固本陪源，归根结底还是要培养自身的技术力量，多学习互联网公司以及银行业的先进经验。
“去O”的应用驱动分析
从技术角度，没有什么是绝对不能做的，只是看代价多少，以及是否合适。
比如，当年阿里还没“去IOE”时候，浙江移动某些系统就在用MySQL了。MySQL不是天使，Oracle（甲骨文）也不是妖魔，关键还是要看用户的技术场景和技术管理机制。适合你的，就是好的。
此外，浙江移动2011年的CRM项目，包括我们自己做的一些技术创新，都基本证明了在运营商生态环境下，“去I”和“去E”这两件事情，都没有大的技术难点，难点在于“去O”。
从技术能力储备和管理体系分析方面我们就可以看出一些端倪。像阿里巴巴这样的互联网公司，它们自己掌握开发人员，自己掌握架构，其中又包含了应用架构、技术架构和数据架构。阿里巴巴的技术团队的薪酬管理体系，很能体现技术人员的价值，适合技术人员生存发展。在这种环境下，开源数据库的缺点完全可以靠自己培养的、国内少见的代码级专家来解决，开源数据库与应用可以做到高度融合。
运营商的情况却完全不同。由于开发长期完全外包，自己几乎没有研发技术人员，体制内也缺乏技术人员的发展环境，这导致十多年前培养起来的真正具备动手能力的少量第一代技术骨干，正随着时间流逝风雨飘摇。与此同时，新生力量又顶不上来。现状是，运营商对核心能力的掌控非常有限。相对来说，技术架构的掌控还算得力，但应用架构和数据架构已经成为现实的重灾区。最终，在运营商生态环境中，可以对MySQL进行代码级掌控的元素已基本缺失。
实际上，阿里巴巴做去IOE有其业务发展上的原因。
对于互联网和传统企业来讲，最终都得为用户服务。因此其希望尽量减少收费和依赖，变成一个尽可能廉价且拥有性价比的公共服务平台，在这个平台上则可以产生出更好的服务。而运营商的应用场景目前来看，比较明确的还是私有云，并且希望通过“去O”加强自身核心能力的建设，减少对合作伙伴的依赖，剑指亚联这样的开发商和Oracle这样的平台提供商。
很多人认为，阿里巴巴“去O”的技术原因，是Oracle不能满足互联网业务的可扩展性需求。我觉得这个理论可能是站不住脚的。充分利用闪存混合架构，MySQL的单库容量都能提高，更何况Oracle数据库？而且还有Exadata这样的产品来为Oracle“撑腰”。在海量数据的处理方面，直接用Hadoop、NoSQL就可以，本来就和“去O”这种使用场合的议题扯不到一起。
“去O”的技术难点
“去O”需要考虑以下几个方面的问题。首先是数据一致性。具体操作上，这需要看不同的业务需求，但是运营商的核心系统一般是有强一致性要求的。此外，还要关注复杂查询支持、单机扩展性以及优化的成熟度三个方面。 、
这几个问题，会显著增加业务开发的复杂度， 因为必须将这部分功能的需求，在应用层实现。对于技术储备一般的公司来讲， 这就是非常高的门槛了。而运营商，在这几方面也正好“中枪”。
因为“去O”必须将部分原本已经在数据库层实现很好的功能去掉，交给应用来做，因此这往往会造成开发浪费。对于阿里巴巴这样拥有开发实力的互联网公司来说，从业务角度看是值得投入的，但对运营商来说，完全可能是自找麻烦。
运营商最好的办法，是向互联网公司学习改革，创造机制培养自己技术人员。如果做不到，那在数据库这种核心平台相关的架构上，或许还真不如用那些国际大公司的产品。
从技术生态环境的角度看，不可否认的是，Oracle的数据库产品确实出色，特别是在较为传统的OLTP和OLAP场景下更加如此。事实上，开放和封闭的差别，不仅仅存在于代码环节，还存在于技术支持环节。而在移动环境下，后者比前者更加重要。Oracle数据库有非常开放的技术文档，带来了极度繁荣的、独一无二的第三方技术支持市场。
“去O”不是直接上MySQL，产品的选择不是儿戏，不能简单抄袭。还是那句话，环境不同，别人适合的东西不一定适合自己，反之亦然。此外，选择产品本身也可能涉及到技术路线的选择。MySQL和Oracle相比功能要简单得多，很多复杂查询不支持，数据结构很多需要转换，语法也差别较大。也就是说，如果把程序从Oracle割接到MySQL，数据倒换代价不说，代码基本上兼容性较低，需要重写的部分占比应该会很高。而现实情况是，运营商对业务连续性的要求极高，但技术掌控力又不如互联网企业。这种情况下，想象一下运营商的系统“去O”会面临什么样的挑战？
运营商该如何对待“去O”？
没有金刚钻，别揽瓷器活。“去O”有风险，操作需谨慎。在这个问题上，不能被一些人云山雾罩地一吹就晕，一味照搬互联网公司的做法，简单粗暴地快速全面“去O”，那样很容易搬起石头砸自己的脚。场景不同，还是要实事求是，因地制宜，不能脱离实际。
运营商应该把精力，花在局方和第三方Oracle技术支持力量的培养上。市场上有那么多专业的第三方合作伙伴，全国一盘棋，是否能在技术支援体制上做文章，改变现有的各省“烟囱式”技术团队的现状？运营商内部好的甲乙方技术力量，是否可以复用创造更大的效益？
如果确实要这么干，那么应该从对数据的强一致性、数据库的可扩展性、安全性等要求相对不高的系统入手，逐渐积累经验，锻炼队伍，逐步深入。或许有那么一天，我们能将“去O”落实到我们的核心系统中，但这一天应该不会马上到来。要知道，技术掌控力强于多数运营商的阿里巴巴，目前真正涉及到钱款交易的支付宝核心系统，仍然在使用Oracle。可以看到，互联网公司的“去O”进程，也是由浅入深，由外向内的，这一点值得借鉴。
此外，运营商也可以考虑一下国产数据库，走国产库的路是符合社会特点的。
很多人一谈到国产数据库就嗤之以鼻，笔者认为这种态度不可取。现在国货或许还不行，但我们还是要努力培养，让其尽可能茁壮成长。至少，目前国产数据库与Oracle代码在纸面上的兼容性要强于MySQL，而且不同程度地支持与Oracle的异构容灾。国产数据库发展壮大，我想也不是完全没有可能，没准我们的国产数据库厂家也能成为下一个华为呢？
总之，“去O”数据库产品的选择，本质是在运营商环境下不同技术路线的选择。西药立竿见影，中药固本陪源，归根结底还是要培养自身技术力量，多学习互联网公司以及银行业的先进经验。只要正确理解、有机汲取互联网行业的先进技术思路，结合运营商的现实环境情况，开拓思维，勇于创新，我们一定能走出一条我们自己的有运营商特色的“去O”之路来。
总之，“去O”数据库产品的选择，本质是在运营商环境下不同技术路线的选择。西药立竿见影，中药固本陪源，归根结底还是要培养自身的技术力量，多学习互联网公司以及银行业的先进经验。