技术的开放性

可能是真的老了，最近半个月时间两次把钥匙锁在家里。周一早上上班的时候，正在想着一个方案的问题，出门把房门锁上才发现除了一部手机，其他啥也没拿。走到一半发现没带口罩，找了旁边的几家药店，都还没开门，确实也是，7点多钟，哪家药店会开门呢。硬着头皮到地铁站试试，大妈苦口婆心的让我马上去买个口罩再进站。这大早上的，卖口罩的黄牛都还没上班，也真是没招了。幸亏还有手机在手，刷了一部桔子单车，骑了四公里多路，到了公司。搞系统运维年头长了，两地三中心架构还是有的，常年在口袋里、电脑包里和办公室的抽屉里放三把钥匙，拿到抽屉里的钥匙，心里也就没这么慌了。前天和老储说起这件事，老储说，人老了，都是单线程架构了，同时做两件事，肯定有一件做不好。想想年轻时候确实可以同时做上七八件事情，而且件件事都做的还不错。

周一让我忘了拿钱包钥匙的那件事就和今天想讨论的技术开放性的话题有关。在大家的印象里，互联网公司是技术开放的典范，确实在现在的开源社区里，国际互联网巨头已经超过了以前的IT大佬，成为技术贡献的绝对主力。不过技术开放性还不是那么的简单，实际上对于使用这些技术的企业来说，技术平台的开放性可能更为重要。互联网公司是十分注重生态建设的，不过这种生态建设往往只是齐小白王霸事业的那种生态，就是一个大佬，带着一群小弟玩的生态。

实际上老白最近头痛的一件事很简单，就是客户的内网RDS和MAXCOMPUTE以及OSS中的数据需要穿透安全隔离网闸，和外网的阿里云做双向复制。可能有朋友会十分惊讶了，这才多大点的事儿啊，用阿里的DTS，分分钟就可以搞定的事情。确实也是，刚开始的时候，老白也没把这个工作当回事，因为事先老白有OGG复制穿透安全隔离网闸的经验，通过OGG提供的消息接口，老白很容易的把以前在内网中的OGG复制扩展到了内外网间的复制。那么DTS复制照猫画虎就可以了，从DTS订阅消息，取出消息，然后用我们的安全穿透工具穿透内外网，再把消息回写到DTS的消费队列里，由DTS回写到目标库。于是开始找DTS的资料进行分析，发现阿里这种大厂的技术资料居然简单到了连我们这个几十人的小团队都不如的地步，看DTS的资料根本无法获得任何有价值的信息。于是找阿里的销售协调技术人员，问了几个人，说法居然都不太一致，不过隐隐的感受到这件事恐怕不那么简单。DTS是一个完全一体化的体系，说一体化那真是无奈的说法，说的不好听一点，就是DTS完全没有留有第三发开发或者扩展的能力，数据抽取，数据传播，订阅，消费都是完全封闭的。还好，老白的白鳝的洞穴里还是人才济济的，不少人玩过阿里云和DTS，告诉老白DTS的消息支持订阅，于是又认真的去翻了几遍DTS的开发者手册，里面确实讲到了配置订阅通道的API，不过就是找不到DTS读取订阅消息以及将一个消息写入DTS消费队列的API。于是又是一通查资料未果后，再和网友交流，终于弄清楚了，DTS是不支持消息回写的，后面的消费模块需要我们自己解决了。

还好这个问题目前还是找到了解决的方案，在和网友沟通的时候，大家都提出了一个观点，就是阿里云，上云易，下云难，整个体系的封闭程度让很多有个性化需求的用户十分难受。更麻烦的是阿里的售后服务体系几乎是没有的，遇到问题除了在阿里云的论坛里提问或者网友之间互相交流外，几乎没有更好的办法。

想起前阵子和阿里合作的几个项目，或多或少都存在这样的问题，做区域负载均衡，必须使用阿里的底座，必须使用RDS等阿里云的组件，甚至不能在ECS上自建数据库；运维自动化系统，阿里采集了大量的运维数据，不过这些数据都是以常人无法直接使用的格式存放在数据库里的，而且不提供任何外部输出的接口，想在阿里平台外围开发更大的平台需要阿里定制开发接口才行，让阿里云纳管非阿里云的运维对象，又不支持，整个项目就陷入了僵局。

想想当年小型机打败大型机、UNIX系统打败MVS\VMS等优秀的专用操纵系统，都是开放技术架构的胜利。目前的互联网巨头比其当年的IBM/DEC来说，地位也大致相当，担当的角色也大致相当，干的却是当年失败者干的事情，这一点还是值得反思的。

说到技术的开放，华为是另外一个极端。这个最喜欢建生态的企业，是生态最大的受益者，也是最大的生态破坏者。华为生态建设的开放程度要远高于天朝的互联网巨头，很多业务也是靠生态才发展起来的。不过华为的生态对于参与其中的企业来说也是有风险的，只要被华为看上的业务，就会吃的一干二净。这种开放的生态，实际上也是一种假开放，真正的开放生态，应该是多个巨头参与的，存在一定制约的生态系统，任何人不想好好玩，都可以滚蛋，其他人照样可以玩的很好。只有这样的生态，才可以持久。