2015年中国公有云服务发展报告——服务运营篇（下）

背景介绍

2015 年 12 月，InfoQ 的编辑魏星邀请作者撰写一篇关于中国公有云服务发展状况的文章。因为作者个人对公有云这个领域一直抱有很大的兴趣，便贸然答应了下来。在这篇文章的准备过程中，作者系统地阅读了国内较为知名的几份云计算白皮书 [1，2，3]。作者发现这些报告大都高瞻远瞩提纲挈领，缺乏对具体的公有云服务提供商的描述，未能让读者一窥国内公有云服务发展之真实面貌。在 InfoQ 的协调下，作者与国内多家公有云服务提供商的主要负责人进行了电话访谈，围绕团队建设、产品研发、服务运营这三个问题进行了讨论。除此之外，作者也在本文所探讨的所有公有云上都注册了账号，从用户体检的角度进行了一些小规模的测试。这篇文章的目的，便是从团队建设、产品研发、服务运营、用户体验等四个方面对中国的公有云服务发展状况做一个简要的综述。

根据美国国家标准技术研究院（NIST）的定义 [4]，云计算在服务模型上可以划分为软件即服务（SaaS）、平台即服务（PaaS）和设施即服务（IaaS），在发布模型上又可以划分为私有云、社区云、公有云和混合云。需要说明的是，随着云计算技术的发展，如上所述服务模型和发布模型之间的界限也日趋模糊。在本文的范畴内，“公有云”一词泛指面向公众开放服务的平台即服务和设施即服务。除此之外，各种名义的私有云（Private Cloud）、专有云（Dedicated Cloud）、托管云（Managed Cloud）均未包括在本文的范畴之中。

本文中“团队建设”、“产品研发”、“服务运营”三个小节的数据来源有两个。一个是云服务提供商主动发布的新闻资讯，另一个是作者与云服务提供商的主要负责人之间的电话访谈。作者与黄允松（青云）、季昕华（UCloud）、李爽（美团云）、钱广杰（盛大云）、沈志华（又拍云）、王慧星（腾讯云）、许式伟（七牛云）、朱桦（金山云）等业内专家（按姓氏拼音排序）的访谈，是由 InfoQ 方面统一协调安排的，在此作者深表感谢。这个三个小节的内容，在定稿之前均经过受访者及其公关 / 市场团队的确认，反映的是云服务提供商自身的观点和思路。在审稿阶段，青云撤回了与作者进行访谈时所发表的一切言论；出于保护商业机密的考虑，阿里云拒绝了作者的访谈邀请。因此，如上三个小节未能包括青云和阿里云的观点。

“用户体验”和“其他讨论”这两个小节，是作者独立获得的数据以及由此引出的观点，在定稿之前未接受任何一家云服务提供商的审核。需要特别说明的是，如上所述云服务提供商的主要负责人接受作者的访谈并不代表他们认可作者在“用户体验”和“其他讨论”这两个小节中所报告的数据和观点。此外，作者本人也并不持有本文中所讨论的任何一家云服务提供商的内幕信息，作者独立获得的数据仅仅是基于作者所使用的测试方法得到的观测结果。受种种技术条件的限制，作者无法对这些数据的准确性进行背书，也无法对其误差范围进行估算。本文中报告的大部分数据是在 2016 年 3 月底之前获得的，这部分数据的获取时间在正文中不再特别说明；小部分数据是在 2016 年 8 月底获得的，这部分数据的获取时间在正文中会有特别说明。读者在引用本文所报告之数据时，应当考虑到数据的时效性。

本文中有多个小节对各个云服务提供商进行了逐一介绍。相关云服务提供商在这几个小节中出现的顺序是按照拼音字母次序排列的。

本文仅讨论中国本土的公有云服务提供商。Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform 等等进入或者未进入中国市场的外资企业不在本文的讨论范围之内。

服务运营（下）

腾讯云

腾讯云从北京、上海、广州、香港、多伦多提供服务。腾讯云的选址决策是基于 QQ 和微信产品的热力图做出的。哪里人多，腾讯云就选址在哪里。中国的经济版图，基本上就是华南、华中、华北，集中了中国的人才和财力。选址香港是因为腾讯总部在深圳，选址北美是因为腾讯当时使用过 AWS 等相关服务，多伦多这个点是和 SoftLayer 合作的，北美的网络连通性比较简单，具体的地理位置不是很重要。2016 年腾讯云将东南亚数据中心提上日程。腾讯云在各个数据中心都有经理，有一个本地化的团队进行运维。

不同地理位置之间的网络是打通的。譬如说一个用户在北京和上海两个区域分别开一台云服务器，这两台云服务器是可以放在在同一个子网里的。有这种需求的用户并不多，通常是超大体量的公司才会有这样的需求。开发这个功能，主要是考虑到容灾和负载分布。譬如说，北方的用户连接到北方的 IDC，用户体验会好一些。

对于突发事件（包括不可抗力和人为事故）的处理，腾讯云有一套应急预案。譬如说天津港爆炸事件，腾讯云启动了应急措施，非常好地保障了服务，完整的服务没有受到任何影响。

如何应对来自内网和外网的攻击行为，譬如端口扫描，腾讯云给用户提供了安全服务，用户可以选择是否开通。如果用户选择开通，腾讯云会在用户的操作系统里面安装 agent。用户可以选择用户信得过的 agent。腾讯云认为需要给公众的客户传播这样的理念：选择大的公司如腾讯云、阿里云、AWS，使用他们提供的 agent 其实是没有风险的。这些东西是放在阳光下的，agent 做了什么事情，都是可以知道的，没有必要太担心。大的厂商，在安全方面都有巨大的投入，用 agent 比不用 agent 要好。

腾讯云的帐号体系是与 QQ 号码绑定的。QQ 号码背后是一整套的账号管理系统，可以是 QQ、可以是邮箱、可以是电话号码。如果用户不打算使用 QQ，简单地把它当作一个邮箱使用也是 OK 的。腾讯云慢慢地也要支持更多的实名认证方式。譬如说 2C 类型的用户，已经可以使用微信支付的方式来购买云主机了。在用户体验这一块，腾讯云是愿意不断优化的。

在公网 IP 方面，腾讯云使用自己的 IPv4 储备。腾讯云也有弹性 IP（Elastic IP，EIP）的功能，用户可以按需使用，不需要的时候就是放掉。腾讯云的公网 IP 是够用的，不会对腾讯云未来的发展造成障碍。

在腾讯云所提供的虚拟机中，Windows 操作系统的比例要远高于 15%，但是也没有 50%。在腾讯云里还有一部分物理机托管业务，这部分的业务从外界看不出来。在游戏领域，腾讯云是最大的服务提供商。游戏类客户使用 Windows 的比例非常高，因此腾讯云的 Windows 操作系统比例会比阿里云高一些。在 IDC 里面，如果游戏类客户比较多的话，可能会发现 Windows 操作系统占 40% 到 50%。

腾讯云的主要竞争对手更多还是比较传统的 IDC，比如说世纪互联。迁移到腾讯云的客户，很多都是从传统 IDC 迁移过来的。腾讯云的估算是传统 IDC 在数据中心市场的占比还在 9 成以上。

国内公有云服务的价格是比较低的。如果和 AWS 的价格相比，AWS 的定价比国内要高。两、三年前，国内友商都在通过下调价格来占领市场。但是最近大家有一些默契，认为应该提高产品的能力，提高对用户的价值，不要把价格压下去。企业客户并不是真的非常对价格敏感，而是希望价格合理。腾讯云不希望在某个产品或者功能点上做价格的 PK 去迎合用户，这样的模式很难持续。

在用户忠诚度这个问题上，腾讯云觉得首要在于练好内功，不能要求客户对你忠诚。就像任何人之间的交往，你要给对方带去价值，对方才会给你带来回报。

关于 OpenStack 和 OpenStack 生态圈，腾讯云认为这样一套体系非常完整。腾讯云也在和国内一些 OpenStack 厂商合作推出混合云解决方案。在金融领域，私有云的需求很强烈。用户对资源的要求弹性比较大的，建议优先在公有云上做。如果用户愿意支付相应的成本，则可以在 OpenStack 上实现。OpenStack 和公有云的发展，应该是互相促进的关系。私有的 IDC 必定是单点的，用户需要为所有的资源买单。使用公有云，则只需要为你使用的时段和服务买单。公有云很重要的一点，在于它的网络是否真的四通八达。

UCloud

UCloud 分别从北京、广东、香港和北美四个不同的地理区域提供服务。这个选址决定是因为 UCloud 最初的客户分布，他们的用户基本上都在北京、上海、广深。选择香港和北美，是因为 UCloud 的客户有往香港和北美拓展业务的需求。UCloud 在北京和广东部署了自己的运维人员，但是在香港和北美没有。UCloud 在海外节点的部署和扩容基本上是自动化的，只要厂商把设备运到机房，机房帮我们把设备放上去就 OK 了。

在服务等级协议（SLA）的设计方面，UCloud 分为三个阶段去进行。第一阶段是了解用户需求，也就是他们能够接受什么样的 SLA。根据 UCloud 研发人员从在腾讯和盛大学习到的经验，对用户的需求和期望值有一个初步了解。第二阶段是设计，从理论上计算我们能达到什么水平。第三阶段是改进，从实际运行数据计算、验证、改进。

在突发事件（包括不可抗力和人为事故）的处理方面，有两个问题不是 UCloud 能够控制的。一个是机房问题，一个是全国性网络问题。其他友商遇到过光纤被挖断、电力被雷击的问题。UCloud 的侧重点在于机房掉电之后如何迅速地把用户的业务从一个机房转移到另外一个机房。

应对来自内网和外网的攻击行为，譬如端口扫描，是 UCloud 的优势和特长。在安全方面，UCloud 采取应对措施有三个。第一是区分职责，UCloud 处理网络底层，保障网络的安全可靠，防 DDoS 等等虚拟机以外的攻击行为，用户则负责虚拟机以内的攻击行为。第二是引进第三方安全解决方案。第三是建立内部操作审计系统，进行镜像分析。UCloud 严格限制内部工作人员接触或者读取用户的镜像。对于在用户的虚拟机内部预装 agent 的行为，UCloud 是严格禁止的。虽然这样在管理上非常不方便，但是用户会认为 UCloud 是可信的。在网络隔离方面，UCloud 从 2012 年开始就给所有用户默认创建一个私有网络，内网不能扫描，但是公网还是能扫描。内部隔离是必然要做的事情。用户还可以通过公网的防火墙来限制访问。

UCloud 通常提前半年对机房资源进行整体准备，根据用户业务需求对资源进行动态扩容，保证 25% 到 30% 之间的空闲资源。当空闲资源小于 25% 时就会对机房进行扩容。每个月都会对下个月的资源需求情况进行预测，制定每周的资源增长计划表。对于大的客户，有客户经理事先沟通，提前了解他们对计算资源的需求情况。通过如上三个措施，确保我们的资源是足够的充分的。

UCloud 没有超售的情况，因为我们的客户和其他客户很不一样。个人客户一般就放一个网站，一个月可能只有一两次百度爬虫的访问。对于这种类型的客户，是有很大超售空间的。但是 UCloud 的客户都是企业客户，他们对 CPU 资源的使用要求是很高的，所以很难去做超售。CPU 和内存是最难复用的。IP 资源是绝对复用不了的。

在公网 IP 方面，UCloud 有两个 B 段的 IPv4 储备，同时也使用运营商提供的公网 IP。此外，UCloud 还在准备自己的 BGP 和 AS 编号。在 UCloud 所提供的云主机中，Linux 操作系统大概占 90% 左右，Windows 操作系统只有 10% 左右。UCloud 没有个人客户。就好像一句话这样说：“如果你什么都信仰的话，等于你没有信仰。”服务客户也是如此，如果你谁都想服务好，那只能谁都服务不好。

在虚拟化产品和非虚拟化产品的比例方面，92% 到 95% 是虚拟服务器，5% 到 8% 是物理服务器。使用物理服务器的客户，基本上都是 2013 年之前的客户，我们也称为有历史包袱的客户。2013 年之后的客户，大部分都用云计算了，没有历史包袱。在 2013 年之前，云计算还没有那么流行，只能用物理机。这些用户的体量可能不大，但是对 UCloud 的战略意义很强，所以要把它们拉进来。UCloud 的目标是先把他们拉进来，等到他们的服务器生命周期到了再逐步转到云上，这就是这些客户的价值。UCloud 云认为 0 和 1 之间是有灰度的。UCloud 提供的产品，在帮助客户彻底转换到云计算之前，能够有一个混合的模式来保护客户的投资。这也是一种对客户负责任的态度。

UCloud 的主要竞争对手是阿里云。市场份额则不好确定，因为大部分公司都没有公布业务数据，分母和分子都是未知数。在定价策略上，UCloud 的价格略高于行业平均水平。UCloud 认为企业客户关心稳定性和可靠性，UCloud 要让优质的产品有更好的价格，这样才能够真正解决中国大部分行业要靠低价取胜的思路。这也就是供给侧改革，好的商品是有价值的，好的服务是有价值的。所以 UCloud 的价格虽然会贵一些，但是企业是会接受的。这也就是为什么 UCloud 不做个人客户。这个定价策略和 UCloud 的目标客户群是一致的。UCloud 的客户都是企业级客户。只要你服务好，稳定性好，他是不会因为价格问题离开的。所以 UCloud 的客户流失率非常低，并且越是大客户越是低。

在规模上，UCloud 最大的一个客户拥有的主机数量超过 1 万台。UCloud 的整体规模大于 10 万台云主机。运行在 UCloud 上的云主机，大部分都需要公网 IP，除非是数据库等内部业务。但是 UCloud 并没有一个详细的统计数据。从数量来说，因为 UCloud 的中小客户比较多，他们的主机大多数是有公网 IP 的。对于大客户来说，内网 IP 会比外网 IP 多。针对“云主机是一个赔钱的生意，云计算赚钱的业务是存储和网络”这样的观点，UCloud 没有这样分开计算过。

未来 CDN 是一个非常重要的方向。娱乐产业起来了，基于手机的视频点播和直播需求很大。CDN 厂商有明显的优势，譬如网宿。地区性的 IDC 还需要时间来改进和完善他们的全国布点。

OpenStack 最近的发展趋势是非常快的，UCLoud 也在学习和了解 OpenStack。UCloud 和全球第一大 OpenStack 服务提供商 Mirantis 合资在国内成立一个公司，通过这个合资公司去满足客户在私有云方面的要求。目前 OpenStack 已经成为开源社区最有活力、贡献最大的开源项目了。但是 UCloud 没有看到用 OpenStack 做公有云做的好的公司。OpenStack 在私有云领域有相当大的影响力，能够满足相当多用户的需求，但是它做公有云还是有压力的。因此，UCloud 的公有云是自己研发的，私有云则和 Mirantis 联合提供基于 OpenStack 的解决方案，能够满足用户的混合云的需求。

很多人认为云计算就是做 IDC 生意的，UCloud 对此并不赞同。我们认为云计算有五个阶段。第一是替换 IDC 和服务器设备。这个领域大概 1100 亿到 1300 亿的年产值，目前云计算所占的比例还非常小，需要把基础的计算、存储、网络做好。第二是在计算、存储、网络的基础上，用户会需要托管服务（Hosted Services）。托管服务的好处是资源利用率更高，这是一种软件服务，不是卖主机。软件服务的利润值更高，黏性更强。第三是 UCloud 在 2015 年主推的软件市场——U 市场。软件厂商把他们的解决方法放到 UCloud 上来，UCloud 帮助他们推广，形成企业级的软件应用市场（企业级的 App Store）。第四是打造服务的应用市场，引进为中小企业和传统企业做服务的公司，譬如运维服务、开发服务、安全服务。很多公司一个月付十到二十块钱，就能够享受这些服务。第五是大数据阶段，UCloud 目前还没有完善的产品模式。

云计算的价值不仅仅是赚钱。云计算的核心价值是“使用比拥有更有价值”。用户不需要拥有计算资源，他只需要简单的使用就好了。这种转变会改变社会的组织运转模式。人们常说，一个组织最大的资产就是人。现在一个公司不再需要招聘运维人才，这些可以通过云计算自动实现。这就像现在的分享经济，由不属于你公司的员工来帮助你。UCloud 的目标就是通过 API 的模式，帮助客户获得他所需要的资源。淘宝非常伟大，可以帮助客户获得他所需要的商品，但是这还不够。UCloud 的目的，是让有一技之长的人能够在 UCloud 的平台上为用户提供服务，发挥自己的价值。

又拍云

又拍云将云计算定义成一个服务，对服务等级协议（SLA）的要求是第一的。SLA 是一个比较重要的指标。跟客户签约的时候，又拍云会把 SLA 放到合同里面。在研发层面，又拍云通过架构优化设计了自我修复的功能。在运维层面，又拍云通过 7x24 小时的监控，确保出现问题能够及时修复。

众所周知国内网络非常复杂，单纯依靠一个较好的机房或者一个较好的地区去提供服务，不可能达到客户要求。又拍云依靠全局的网络去解决局部性的问题。比如，从南到北，电信和联通之间的长距离传输经常有拥塞，又拍云架构了一个内部网络，不会由于主干网的拥塞而导致网络不可用。公司下了很大的力气来克服国内复杂网络的单点故障问题。又拍云在全国有 150 多个机房，如果某个机房发生了网络中断，公司可以直接把这些机房从基础设施中移除，流量就不会被导向这些机房。对于用户而言，某个机房的单点失效是不可感知的。

云服务更新迭代的速度非常快。又拍云在发布周期和发布进度两个方面都有严格控制。又拍云有一个专门的房间做发布，叫做发布室。新产品上线时需要进行两次发布，一次是预发布（灰度发布），一次是全局发布。灰度发布是发布到 150 多个机房中的 3 个，这时产品和运维人员要集中到发布室，发现问题要及时处理。灰度发布稳定运行 24 小时之后，再全局发布。又拍云不允许某一个人员单独把某一个功能单独发布到产品平台上。

又拍云有三个比较大的防攻击的机房。在遇到 DDoS 攻击时，公司根据 DDoS 的量级来做不同的处理。又拍云的 150 个机房都有一定的上行容量，几百个 GB 的流量攻击属于小量级的攻击，基本上不需要理会。遇到大规模攻击时，又拍云会把相应的流量调度到这 3 个防攻击机房，再把流量分散到其它的机房。在这个方面，公司已积累了一定的算法，筛选攻击来源和攻击对象，在此基础上采取一些更细致的应对措施。同时，又拍云还跟运营商合作，在省级网关那里就把攻击流量给过滤掉，不会下发给又拍云的服务器。

在成长速度方面，又拍云现在全国有 150 多个机房，4000 多台服务器，带宽到了 1.5TB。日均 PV 数量超过 500 亿，新增存储容量超过 5PB。在又拍云所管理的数据当中，热数据比例在 10% 以内，90% 以上是冷数据，带宽主要服务于 10% 以下的热数据。

又拍云已经实现了自动化运维，运维体系非常完善，无需在机房部署又拍云的运维人员。服务器厂商出货，配上又拍云的 U 盘发到数据中心。机房人员帮又拍云上架、加电、开机，从 U 盘启动操作系统，启动完成后自动加入又拍云的集成平台。

又拍云坚持自主定价，不会参考其它友商报价。得益于整体规模的扩大，又拍云的优势得以展现，在此前提下，又拍云做过几次幅度很大的调价行为。又拍云的产品定价非常纯粹，基于服务能力和成本，制定一个比较合理的价格。因此，又拍云的调价并不是为了获得竞争优势或者占领市场。

又拍云本身是一家创业型公司，非常注重处于创业期的客户。又拍云是目的培养两三年以后的客户，会对创业型的客户做很大的支持工作。公司把自己和客户绑定在一起，和客户一起发展。

目前，又拍云客户流失率非常低，客户忠诚度非常高。客户把又拍云当成亲密的合作伙伴，又拍云也把客户作为公司的合作伙伴。这跟又拍云的基因有很大的关系。云计算本身就是一种服务，服务质量好，产品够稳定、够好，用户把东西放在这里会非常放心。对于服务型的公司来说，客户的忠诚度体现在你能够给客户做什么东西。

又拍云的目标是打造一个综合的云服务，或者说是一个可编程的 CDN。用户可以在又拍云的 CDN 平台上做开发，不需要单独购买云主机或者是物理机，也不需要区分云主机和云存储。在又拍云这个综合的云服务上，计算可以发生在不同的层面，譬如说计算可以发生在最前端。从大的方向来说，又拍云类似于 AWS 推出的 Lambda 产品，但是要比 Lambda 更贴近用户。

信息披露

作者蒋清野是悉尼大学信息技术学院的博士研究生，同时也是 AWS 悉尼技术支持中心的员工。他于 1999 年获得清华大学学士学位（土木工程），2000 年获得伊利诺伊大学香槟分校硕士学位（土木工程），2015 年获得悉尼大学硕士学位（计算机科学）。他的研究兴趣包括分布式与高性能计算、开源社区的社会学行为、信息技术领域的微观经济学分析。他是美国电子电气工程师学会（IEEE）的高级会员。

在接受 InfoQ 方面的邀请准备规划这篇报告的时候，作者的内心是兴奋的。在获得所有测试数据准备撰写这篇报告的时候，作者的内心是矛盾的。一方面，作为并行与分布式计算领域的学生，作者希望为业界提供一些有用的信息和观点；另一方面，作为公有云服务领域的从业人员，作者深知发表一份涉及多家友商的报告会带来诸多争议。在 InfoQ 方面的鼓励下，作者选择以真实的身份发布这些的数据和观点，希望能够对国内云计算从业人员有所帮助。

参考文献

1. 工业和信息化部电信研究院（中国信通院，CAICT），《云计算白皮书（2014 年）》，2014 年 5 月
2. 中国电子信息产业发展研究院工业和信息化部赛迪智库，《云计算发展白皮书（2015 版）》，2015 年 4 月
3. 工业和信息化部电信研究院（中国信通院，CAICT），《云计算白皮书（2016 年）》，2016 年 9 月
4. Peter Mell and Timothy Grance, “ The NIST Definition of Cloud Computing ”, NIST Special Publication 800-145, September 2011
5. William Stanley Jevons, “ The Coal Question ”, 1866
6. 蒋清野，《虚拟化、云计算、开放源代码及其他》，2012 年 10 月
7. 蒋清野，《从王博士说起》，2013 年 12 月
8. 蒋清野，《浅谈“中国”语境下的公有云发展》，2015 年 5 月
9. Qingye Jiang, Young Choon Lee, Albert Y. Zomaya, “ Price Elasticity in the Enterprise Computing Resource Market ”, IEEE Cloud Computing, vol.3, no. 1, pp. 24-31, Jan.-Feb. 2016, doi:10.1109/MCC.2016.14
10. 章文嵩，《淘宝软件基础设施构建实践》，第三届中国云计算大会，2011 年 5 月
11. 高山渊，《阿里巴巴系统运维实践分享》，QClub 深圳站，2012 年 6 月
12. Netcraft, “ Aliyun cloud growth makes Alibaba largest hosting company in China ”, May 2015
13. Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang, “ FuxiSort “, Alibaba Group Inc, October 2015
14. Reynold Xin, Parviz Deyhim, Ali Ghodsi, Xiangrui Meng, Matei Zaharia, “ GraySort on Apache Spark by Databricks “, Databricks Inc., October 2014
15. Michael Conley, Amin Vahdat, George Porter, “ TritonSort 2014 “, University of California at San Diego, 2014
16. Intel Xeon E5-2630 基准测试数据
17. Intel Xeon E5-2650 基准测试数据
18. Intel Xeon E5-2670 基准测试数据
19. Thomas Graves, “ GraySort and MinuteSort at Yahoo on Hadoop 0.23 “, Yahoo!, May 2013
20. Zhuo Zhang, Chao Li, Yangyu Tao, Renyu Yang, Hong Tang, and Jie Xu. “ Fuxi: a fault-tolerant resource management and job scheduling system at internet scale. ” Proceedings of the VLDB Endowment 7, no. 13 (2014): 1393-1404.
21. 华为集团，《华为服务器助力腾讯构建十万级高效部署》，2014 年 7 月
22. 陈海泉，《下一代超大规模软件定义网络技术实践》，2016 年 1 月
23. 高旭磊，《招商银行关于金融云的思考》，中国金融电脑，2016 年 8 月
24. 阿里云，《阿里云生态路线图》，2015 年 7 月

感谢魏星对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。