云服务 UCloud 已经不是 UCloud，而你大爷还是你大爷 [2017/12/25 更新]
引
距离我最早开始用 UCloud，已经过去了 3 年多了。如果算上知道 UCloud 那就更早了。像这样起步早期的云厂商，不得不说是非常艰辛的，特别是在那个 OpenStack 还是非常不成熟的年代，要么选择大幅改动二次开发 OpenStack，否则就要选择自研。如果是阿里这样资金允许其投入的公司，从一上来就目标定在对标 Amazon Web Services 上是可能的。而像 UCloud 这样的公司，通过自研走出的道路可以说是非常艰辛的。
让 UCloud 在当时留在公众视野中最深刻的一件事就是其优质的客户服务。当中小手游厂商的工单在阿里云被放置 play 的时候，UCloud 良好的售后抢夺了大量市场，最终站稳了脚跟。然而在今天，公有云的开荒期已过。公有云厂商一方面提供私有云部署，另一方面开始提供进一步的服务以丰富产品开拓新市场。例如托管的云数据库、消息队列、缓存等等，并且在这些问题上进行进一步的开发，使其在云平台上拥有更大的竞争力。
这一步 Amazon 的步子迈得很大，阿里云也紧随其后。前几天的时候，接到一个 UCloud 的电话，问我有没有兴趣参加他们的用户开放日「数据库专场」。这不去不知道，一去吓一跳。我现在甚至怀疑，UCloud 良好的售后甚至不一定是好事，他们对客户的重视，已经远超过了对产品本身的重视。这已经落入了一个做企业服务的公司常常遇到的问题。
为什么要这么说，我一定要说一下今天这个 UCloud 的开放日。
UDDB
今天 UCloud 开发日的主题是数据库，主角是 UCloud 自研的分布式数据库 UDDB，UDDB 的架构相当简单，其原理就是 MySQL Shard，每一个 Shard 单独做 Replication，通过 Stateless 的 Middleware Cluster 进行 reduce 操作并作为入口。这个产品的完成度非常低，Sharding 需要手动设计，跨表查询目前支持性有问题。
但无论如何，开发一个分布式系统是相当难的，要解决的问题有很多。我问了一些问题，得到的答案只能用匪夷所思来形容：
我：Sharding 需要手动指定，是不是基于 ORM 做 schema-migration 的需要额外开发插件？
讲师：Migration 是什么？
我：Migration 就是 ......
讲师：我们没听到过客户用这种东西的。
（好家伙，原来 UCloud 根本就没把 Ruby China 当回事。）
我：怎么保证分布式一致性？
讲师：我们在中间件上做了二阶段提交，需要确认单个机器返回了成功才行。
我：二阶段提交并不能完全解决你的问题，你的单个实例本身是一个 MySQL Replication，如果返回成功的瞬间主机宕机，不能保证备机成功了。
讲师：MySQL 自己会解决这一问题。
（蛤？如果你的 MySQL 没有用 sync 模式，显然是不能解决这一问题的。）
我：你们如何测试你们的系统和 MySQL 的兼容性？
讲师：我们做了一些自动化测试。
我：你们是说通过了 MySQL 自己的测试集还是怎么？
讲师：是的。
我：MySQL 自己的测试集并不能保证分布式本身的测试。比如 AWS 和 TiDB 他们做了……的测试，发现了原先没有发现到的一致性上的……的问题。
讲师：TiDB 那是追求新鲜事物，我们还是比较踏实的。
（分布式测试都不完备还叫踏实，你牛逼）
NewSQL
稍作休息后进入了第二个阶段，这个阶段彻底点燃了我的怒点。在这一阶段，讲师开始介绍数据库的发展历史，当讲到 NewSQL 的时候，用的说法是，因为发现了 NoSQL 的各种事务性和业务上的问题，数据库的发展又回到了 SQL。
如果这一点单指 SQL 的接口，那我也就认了。但 NewSQL 和过去 SQL 的引擎差异巨大，以此来标榜自己 Sharding 一下的 MySQL 也能和 NewSQL 媲美，那完全就是鬼扯。当我还没缓过神来的时候，讲师说：
像 TiDB 现在也号称自己要做 HTAP 而不是 OLTP，所以其确实是不满足大家常见电商或者金融的 OLTP 需求的。我勒个去，听到这里我是彻底听不下去了，然后发生了一下一段对话。
我：等一下，你老实告诉我，你到底是技术人员还是销售，不要装。
讲师：我…我当然是做技术的。
我：那你现在说 HTAP 不满足 OLTP 需求，你知道 HTAP OLTP OLAP 的关系是什么吗？
讲师：是什么？
（还能把问题扔回给我）
我：HTAP 的目的是要做 OLTP 和 OLAP 的超集，同时满足这两者的需求。
讲师：同时做这两者，肯定不能同时满足这两者，肯定是有侧重的嘛？
我：...... OLTP 和 OLAP 本来就不是水火不容的东西，他们两者的区别才是侧重，HTAP 要还是侧重这不是自相矛盾吗？
讲师：那你说说什么电商系统用 TiDB 的？
（我就举了几个大公司在用 TiDB 的例子）
讲师：你也不能只从这个角度来谈 NewSQL。
我：但你现在说的完全都是在泛泛而谈，或者你给我举一个例子说这个 TiDB 相对 MySQL Replication 的系统在 OLTP 上到底有什么「技术问题」。
讲师：TiDB 的问题是 …… 用户少。
（你是想说你 UDDB 用户多吗？）
道德问题
听完这个「用户少」是「技术问题」后，我一个字都没再听下去就摔门走了。第一次参加技术会议能弄得那么生气的。名不副实你在商务上行得通，在技术上是行不通的这不是个常识吗？
如果说你要卖 UDDB，我自然不拦着你。UDDB 确实可以解决一些用户的问题。如果你今天开一个产品分享会，邀请一些传统企业的技术来，讲一下你们的技术，忽悠一下卖出去两份很合理，我一百个支持。但今天非要把产品吹牛上升到技术分享，弄几个销售冒充数据库专家，肆意地诋毁其他产品，这已经不是我能忍耐的地步了。
这个题目如果放在容灾和扩容上吹吹牛，也许还行。放在分布式那么大的一个题目下讨论，自然要通过胡编乱造才能突出自己的产品。还能讲出「用户少」是「技术问题」这种幹话，这世界上恐怕我也就认识 UCloud 这一家了。
公有云的开荒期已过，厂商都在丰富自己的服务。如果 AWS 能做一个 90 分的产品，那么阿里云能做一个 85 分的产品，夸成 90 分。
面对竞争对手一如既往的强势，今天的 UCloud 已经完全不是我以前认识的那个 UCloud。今天 UCloud 做一个 60 分刚及格的产品就来用这种销售的方法吹成 100 分，这不是技术问题。
这是道德问题。
结
UCloud 在圣诞卡里写了：
希望你在活动中有所收获。
我今天最大的收获就是：
不要 浪费你任何一分钟去听一个销售驱动的公司讲技术。
圣诞更新
今天这圣诞夜过得非常有意思，我中午刚睡醒就连着来了两通 UCloud 客户服务的电话来给我解释和道歉这事情。又收到了很多微博私信，咨询我 TiDB 的问题。莫名其妙地兼职了一回 PingCAP 员工。这一波还是同时 PR 两个公司我也是没想到。之后又发现这文章在不少 IaaS 公司里都在传阅，那我有必要来更新一下之后的情况。
删帖
今天还被问了几次删帖的问题。删帖的问题不是不能删，而是删帖其实在造成更大的危害。造成一个事实性的伤害，一个问题，不来解决，而是来解决提出的问题，甚至是解决提出问题的人。如果 UCloud 必须要用这种方法，我相信这也和某些不宜点名的流氓大厂不远了。而且帖子可以被删，但帖子给人们脑中留下的印象永远不会删。如果问题不被解释，连这种文章都要被「公关」，那么今天读过文章的用户和友商们对于 UCloud 只会留下不好的印象，而且互联网是无法被赶尽杀绝的，明天友商上 Web Archive 把文章找出来给客户看，绝对不是好事。既然这件事 UCloud 选择来解释这个问题，那么解释清问题，自然是一个更好的选择。
一些建议
这个问题如果跳到一个更长远的角度来考虑，我确实想对 UCloud，或者国内一些技术公司做类似的事情提一些建议。希望这样的事情不要重演。
首先，就是闭门会。闭门会的意义和面对大量用户的技术分享是有明显区别的。闭门会的形式无外乎两种，做传销式的洗脑，或者针对用户需求解决具体问题。UCloud 试图想做后面那种，于是把它分成五人一个小组的闭门小会。但问题是，定的题目「分布式数据库」绝对不是一个针对用户需求解决具体问题的小问题，甚至是一个非常复杂而抽象的大问题。用户的需求区别可能极大，是讲师无法讲述的，这毫无例外地引发了我认为这个闭门会实际上是想做成传销式的洗脑的会议，更引发另一个问题。也就是对讲师水平的控制的重要性。
在一个公司里找出几个实力绝对过硬的人开多个小会来应付客户各种提问是非常难的，如果被追问，很可能就会引发这样的悲剧。像今天的讲师，对于他所要谈论的「分布式数据库」这样的大题目，只懂一二，甚至连 UDDB 自己可能遇到的一些问题都不自知，这是非常可怕的。UDDB 这个产品能不能用，当然还是什么样类型的需求用什么样的产品。如果对于 NewSQL 这样的新鲜事物还持保守态度，且单实例的 MySQL 无法满足需求，过渡性地作为一个选项也未尝不可，至少在某些公司里确实是这么实践的。做一个 60 分的产品是因为觉得 60 分就足够了是一回事，但如果是只做得出一个 60 分的产品就是问题了。把这样的产品放在公开场合谈论，被 challenge 是分内的事情，如果找个台阶下自然也是合理的。但如果认识不到自己考了 60 分，还要把班级里的学霸批判一番，说他们是追求新鲜事物，自己考 60 分是比较踏实。那就是真的引爆炸药桶的事情。
这样的事既是偶然，也是对演讲品质控制不够重视的必然。
回归问题
据我所知，我当时遇到的讲师在 UCloud 工作的时间也不算短，但有一个非常矛盾的地方在于，PingCAP 本身也是 UCloud 的合作商，TiDB 也在 UCloud 上销售。如果说肆意地诋毁 NewSQL 以及 NewSQL 产品，确实也不太可能是公司授权进行的行为。
如果回归问题的本身，暴露出至少这位 UDDB 的开发对于数据库发展，特别是数据库新技术的认识非常有限。一方面也有护短的思考存在，毕竟是自己做的产品，在被 challenge 到一个非常危险的地步的时候，讲幹话，可能是一种本能行为。但事实上，员工对外 PR 代表了公司的形象，因此造成了对 UCloud 的负面影响，对于公司确实是一个非常倒霉的一个行为，当然我也相信这也不是 UCloud 组织这次活动想要达到的目的。
既然 UCloud 愿意对上述的这些问题作出道歉和保证，我想有这样态度处理这个问题的，至少从骨子里，不是主动希望把自己公司做向一个纯销售烂产品的公司的。当然，承诺是一回事，至于到底只是用户公关的权宜之策，还是 UCloud 以后能贯彻这个承诺，那就要看 UCloud 之后到底做出来的行为和他们说的是不是一致了。
您好，我就是当天分享的 ucloud 研发工程师，有十年多的技术工作经历，目前负责 uddb 的研发。帖子所描述的发生于演讲结束后的 4-5 人小范围的技术讨论，您所谈到的技术点我想有必要说明清楚。
1、首先，是几点我觉得细节上描述的不够清楚的地方
1.1 您说的我没听到过客户用 migration 这种东西，没有把 ruby china 当回事： 当时在和您讨论时您提到的 ruby schema-migration，这个知识点我确实不了解。在您给出解释后，我当时所说是：这个插件的作用是动态做 DDL，但一般而言，DDL 都是由 DBA 在初始化阶段和维护阶段手工做的，所以业务里面直接 DDL 的场景较少。 正所谓闻道有先后，术业有专攻。我们和客户的探讨都是双向的。相互之间会传递各自擅长的技术点给到对方，和客户的讨论过程也是学习的过程。这次了解了 ruby schema-migration，对我来说是一次学习。
1.2 您说的保证分布式一致性的质疑
当时的情况，是我和另外一位客户（我们组总共有 4 位客户）在讨论 UDDB 如何实现分布式事务，所以我介绍了二阶段提交的做法。您在中间插问了节点间多副本一致性的问题，因为当时我们在探讨分布式事务的问题，而多副本一致性问题跟分布式事务无关（是完全独立的两个问题），所以当时我说的是：这并不是我们讨论问题（分布式事务）的范畴。
1.3 针对 TiDB 的几点质疑
您提到 TiDB 对 SQL 解析代码做了形式化的验证，然后发现了几个 bug，同时提到 aws 也有这样的方法。 我认为的是，对 SQL 解析的代码做形式化验证，这是一个不可能有解的问题。UDDB 只是收集了很多 SQL 测试用例来做测试，而 TiDB 这块也是这么做的。
- 另外澄清跟技术有关的几个点：
2.1 关于这个产品的完成度非常低的问题，包括 Sharding 需要手动设计
Sharding 手动设计，具体而言是需要在 Create Table 语句里面，指定分区信息。这是很多分布式数据库的特点。比如，OceanBase、腾讯云 TDSQL 等。而 TiDB，最近也在支持分区。我们认为，Sharding 手动设计是一种给客户更加灵活度的策略，而不是技术上的妥协。
2.2 关于 OLTP 和 HTAP 之争：
我的理解是在讨论一个概念时，需要结合实际的应用场景才有意义。HTAP 从概念上理解，是 OLTP+OLAP，但技术需要结合具体的产品讨论才有意义。正如我当时举得一个阿里云 Hybrid MySQL 的例子，阿里云 Hybrid MySQL 也称之为 HTAP，但假如你看过阿里 Hybrid MySQL 的产品文档，你就会发现，他们文档里面写得很清楚，针对的场景就是物联网、大数据分析等领域，并不是涵盖 OLTP+OLAP（所以我当时反问过你：如果 Hybrid MySQL 能涵盖 OLTP+OLAP，那就是阿里下一代产品了，又为何定位在物联网和大数据分析领域？）。假如你对分布式数据库产品多去了解一点，这个结论是不难得出的。
总结：
本来我觉得这次会议是 4-5 人的一次技术上的小规模的探讨，大家可以放开谈技术的看法和观点，但是引起这些风波是我意料不到的。不过我们还是挺欢迎这种技术上的探讨，客户对我们的批评也是对我们的鞭策和成长，也希望我们后边能针对分布数据领域的技术点有更多更深入的探讨。
moreslowly
等那么久终于等到当事人回应了，如果当事人是这么一个偷换概念的态度和理解，我想实在是非常说明问题的。
分布式事务
当时的情况，是我和另外一位客户（我们组总共有 4 位客户）在讨论 UDDB 如何实现分布式事务，所以我介绍了二阶段提交的做法。您在中间插问了节点间多副本一致性的问题，因为当时我们在探讨分布式事务的问题，而多副本一致性问题跟分布式事务无关（是完全独立的两个问题），所以当时我说的是：这并不是我们讨论问题（分布式事务）的范畴。
我先来给你念念维基百科：
为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。
连一致性都做不到还来谈分布式事务？你是看 2PC 看傻了吧。2PC 协议是分布式事务的解决方案，用于保证属于多个数据分片上的操作的原子性。根本保证不了数据分片内的数据的一致性，完全不适用于 UDDB 的场景。保证不了这一点，也没有任何额外的解决方案，既不满足 ACID，也不满足 BASE，还来谈什么分布式事务，甚至说出事务和一致性是无关独立的问题，也是六得不行。
形式化验证
您提到 TiDB 对 SQL 解析代码做了形式化的验证，然后发现了几个 bug，同时提到 aws 也有这样的方法。我认为的是，对 SQL 解析的代码做形式化验证，这是一个不可能有解的问题。UDDB 只是收集了很多 SQL 测试用例来做测试，而 TiDB 这块也是这么做的。
我和你解释了三遍这个 Formal Verification，倒最后没想到理解的还是「对 SQL 解析代码做了形式化的验证」。被怼了一天一夜，你不会上 Google 查一下到底是做了什么验证吗？
http://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf
这里有一篇 AWS 自己写的 paper，自己念一下再回来说。
OLTP
我的理解是在讨论一个概念时，需要结合实际的应用场景才有意义。HTAP 从概念上理解，是 OLTP+OLAP，但技术需要结合具体的产品讨论才有意义。正如我当时举得一个阿里云 Hybrid MySQL 的例子，阿里云 Hybrid MySQL 也称之为 HTAP，但假如你看过阿里 Hybrid MySQL 的产品文档，你就会发现，他们文档里面写得很清楚，针对的场景就是物联网、大数据分析等领域，并不是涵盖 OLTP+OLAP（所以我当时反问过你：如果 Hybrid MySQL 能涵盖 OLTP+OLAP，那就是阿里下一代产品了，又为何定位在物联网和大数据分析领域？）。假如你对分布式数据库产品多去了解一点，这个结论是不难得出的。
我先不说别的，阿里云的 Hybrid for HTAP 在 Sharding 上还做了分区键。要是阿里云的 Hybrid for HTAP 连 OLTP 都做不到，你个中间件做 reduce 的玩意也敢说自己能做到 OLTP？阿里云怕杀鸡用牛刀说「针对的场景就是物联网、大数据分析等领域」，到你嘴里就变成除了这个就干不了别的了，我也是佩服得不行。
另外既然当时我举的例子既然是 TiDB，你回去打开自家 UCloud 的官方网站
https://www.ucloud.cn/site/product/cloudtidb.html
这里对 TiDB 怎么描述的啊？你要不要继续回去打你东家的脸才开心？
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。
这就是 TiDB 对自己 HTAP 设计目标的描述。
结
本来觉得这个事情造成的影响很大，特别是对 UCloud 公司的影响是超出预期的，也想避免扩大影响。没想到当事人竟来上一篇这么偷换概念的文章，看来是丝毫没有悔改之意，我必须予以驳斥了。
- 首先，你把分片内多副本一致性，和 ACID 一致性混为一谈。ACID 是 Jim Gray 提出来的。我们先来看一下 Jim Gray 在其著作《事务处理：概念和技术》是怎么定义 ACID 中的一致性的：
ACID 中的 C，是指在操作语义上，所有操作的结果对数据库数据造成的影响，必须是一致的。而分片内多副本一致性，是指在分布式系统里（出于容灾或读性能提升考虑，需要多副本），需要多副本部署。这就产生的多副本一致性的问题。
两种办法各有其解决方案。多副本一致性的解决，一般采用 Paxos、Raft 算法，而分布式事务中 C 的保证，目前主流的方法也是采用二阶段提交。如果要细究的话，两阶段提交的方法，对分布式事务中 C 的保证，也是存在局限的。但我相信上面的信息，已经足够解释清楚，为什么分片内多副本一致性，和 ACID 中的一致性，是两个完全不同的概念了。
- 形式化验证的问题
首选必须要指出的是，你回帖的内容：
这里面有一个明显的细节错误。红框中的内容（分布式事务有关的），跟形式化验证没有关系，但是你在这里贴出来了。
个人而言，我认为这是一个不注重细节的表现。
回到 23 号关于形式化验证的讨论。当时我在给另外一为客户，讲解 UDDB 架构的问题。旁边的你突然插问测试的问题。我当时问：是不是指 SQL 覆盖性测试。然后你说是，并说 TiDB 做了形式化（确切地说，你当时用的是 Formal Verification，我翻译成形式化验证是不会有错的）。我当时表达了这不可能。 因为如果能够对 SQL 解析和执行的代码做形式化验证，那么大部分公司都应该不需要测试人员了。
而分片内多副本一致性，是指在分布式系统里（出于容灾或读性能提升考虑，需要多副本），需要多副本部署。这就产生的多副本一致性的问题。
多副本一致性的解决，一般采用 Paxos、Raft 算法，你用了吗？你不是和我说「MySQL 会自己解决的吗？」
在我的个人经验里，任何哪怕具有一点数据库从业经验的技术人员，都应该是能够清晰地识别这个概念的。
对的，所以你不能，你是想说你一点数据库从业经验也没有吗？
moreslowly
回到 23 号关于形式化验证的讨论。当时我在给另外一为客户，讲解 UDDB 架构的问题。旁边的你突然插问测试的问题。我当时问：是不是指 SQL 覆盖性测试。然后你说是，并说 TiDB 做了形式化（确切地说，你当时用的是 Formal Verification，我翻译成形式化验证是不会有错的）。我当时表达了这不可能。因为如果能够对 SQL 代码做形式化验证，那么大部分公司都应该不需要测试人员了。
不要说你翻译的啥，我当时用的就是中文「形式化测试」。我当时问的是「你对架构怎么进行测试的？」你回答说「我们有一些测试」。这句废话回答得很好，我只好接着问，是通过了什么测试，是 MySQL 自己的测试集吗？然后你回答「对，类似的」。我立刻提出，MySQL 自己的测试集不能覆盖这种集群情况，哪怕是已经做了集群测试的 AWS 和 TiDB 也在做了形式化验证后发现了更多问题。到你这里就变成什么玩意了？
是听力不行，理解力不行，还是故意来混淆视听？
至于你说「因为如果能够对 SQL 代码做形式化验证，那么大部分公司都应该不需要测试人员了。 」你这对形式化验证的理解真是弱啊。你形式化验证通过，代表你形式化验证本身是正确的了吗？还来说什么「那么大部分公司都应该不需要测试人员了。 」我看你不但是完全不懂数据库，连测试都不懂吧。
- OLTP 的问题
我先不说别的，阿里云的 Hybrid for HTAP 在 Sharding 上还做了分区键。要是阿里云的 Hybrid for HTAP 连 OLTP 都做不到，你个中间件做 reduce 的玩意也敢说自己能做到 OLTP？阿里云怕杀鸡用牛刀说「针对的场景就是物联网、大数据分析等领域」，到你嘴里就变成除了这个就干不了别的了，我也是佩服得不行。
”你个中间件做 reduce 的玩意“：你可能不知道，阿里云 Hybrid MySQL，就是基于一个中间件发展起来的。你可以去找今年云栖大会上，Hybrid MySQL 负责人的 ppt 和视频。他全面介绍了 Hybrid MySQL 的演进路程。而 UDDB 也是基于一个中间件，在演进。
moreslowly
”你个中间件做 reduce 的玩意“：你可能不知道，阿里云 Hybrid MySQL（请注意：是 MySQL，不是 PG，不要再搞错了），就是基于一个中间件发展起来的。
你先来找找哪里我说 PG 了？
1.OLTP 的问题（续）
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。
我认为这是 TiDB 一个非常好的产品宣传策略。但是这不影响我的观点：
我的理解是在讨论一个概念时，需要结合实际的应用场景才有意义。HTAP 从概念上理解，是 OLTP+OLAP，但技术需要结合具体的产品讨论才有意义。正如我当时举得一个阿里云 Hybrid MySQL 的例子，阿里云 Hybrid MySQL 也称之为 HTAP，但假如你看过阿里 Hybrid MySQL 的产品文档，你就会发现，他们文档里面写得很清楚，针对的场景就是物联网、大数据分析等领域，并不是涵盖 OLTP+OLAP（所以我当时反问过你：如果 Hybrid MySQL 能涵盖 OLTP+OLAP，那就是阿里下一代产品了，又为何定位在物联网和大数据分析领域？）。假如你对分布式数据库产品多去了解一点，这个结论是不难得出的。
我不用查维基，我也知道 ACID 指代的是哪四个单词。这不是一个要背的概念，这是任何一个深入使用数据库的人都应该掌握的知识，也是大学本科教学的内容。不知道是你的问题，不是我的问题，也不是维基百科的问题。
- 谈谈 TiDB
正如我 23 号讨论时所说，我们团队也在学习 TiDB 代码，在我们看来，TiDB 代码是一个优秀的实现。我于今年 5 月份开始，跟 TiDB 的核心骨干，如黄东旭，mengjie、刘寅、邓佺等，都有很好的沟通。UCloud 也和 PingCap 一起，推出了 UCloud TiDB 这款产品。UDDB 团队，和 TiDB 团队，合作也是非常愉快的。比如，我们为 UCloud TiDB 推荐了 2 位客户，而 UCloud TiDB 为我们推荐了 1 位客户。在我们看来，一切以客户价值为皈依。假如客户的业务，更贴合 TiDB，我们则会推荐 TiDB 产品，加入客户业务更贴合 UDDB，则我们向客户推荐 UDDB（其实客户也很聪明，在充分了解两款产品差异性后，自己也知道哪款产品最合适）。
这是我们实际的情况，需要的话我们可以提供信息进行证明。
