十则围之，关于上云的实践与思考

本文正在参加“最佳上云实践”评选，来给我们投票吧：https://yq.aliyun.com/activity/158（编号5）

回首

自1959年ChristopherStrachey发表虚拟化论文，到1984年Sun联合创始人JohnGage提出“网络即计算机”，再到2000年左右的SaaS出现及兴起，云计算服务已经经历了近20年的发展。着眼国内，从吸收概念及技术至今已近10年，然而，相信对于大部分人来说，云还只是临渊羡鱼，如何真正地利用云给业务最大赋能仍然无从参考。

 

我们团队非常幸运地，从阿里云成立开始，就和阿里云的技术团队进行了深入的合作。超过一半的阿里云产品，第一批内测用户就是我们。可以说，阿里云的成长和我们的成长已经深深交织在了一起。我们就是上海云贝网络科技有限公司，人称“网聚宝”。

 

出发

2011年我们刚开始创业，最初托管几台机器，老是断网。而Hadoop最早也有研究，但是创业公司人力资源有限，特别是那个时候的上海；同时，如果只招一个两个肯定不够，搭建、运维、开发，至少也得五六个。限于这些原因，那个时候被竞争对手很被动，他们会说我们有十五六个在搞Hadoop，数据只需要放在自己的机房中，这些对客户来说都有着很大的吸引力，我们也为要不要从0开始完全上云而动摇过。

但是，在阿里云的强力配合和支持下，我们还是坚持了下来，放弃了原有的Hadoop。而随后，到了云变成水电煤基础设施后，对于创业公司来说，云服务已经比Hadoop这些开源软件成熟，这个时候就会发现，这些会应用阿里云的人，业务创造能力是那些Hadoop的许多倍，直接产生业务价值，而用户最需要的就是这些。从而拥有了竞争优势的成本，和业务拓展的速度，来给用户提供大数据处理的能力。

对于原来的那些对手，Hadoop反而成为累赘，积累全在上面，丢掉则放弃了原有的竞争力，不丢掉到底要不要上云，这时候变成了我们乘胜追击的时候。ALL IN云上，为用户提供更多的数据能力。现在我们30个人的团队，就能PK拥有Hadoop团队的百人公司。员工具备业务思维，看得懂背后的需求，和需求背后的价值。

现在想来，是否上云区别就好比汽车与马车的生产力区别，谁胜谁负取决于市场现状。几年前，云还没有那么完善，跑在泥土路上的汽车日子显然没有马车好过，然而随着阿里等有能力的互联网公司建立了足够好的道路后，汽车服务提供商给用户带来的速度与体验显然超过了以往。

 

构建

云计算除了提供开通即用的基础功能之外，我们在使用阿里云产品4年的过程中，也获得了很多基于云计算的架构心得。

不知道其他用户是否有这样的体验：

在使用云服务做架构时，底层基础能力对用户来说相当于一个黑盒，这样我们就可以把注意力放到业务的价值模型和技术的架构模型的统一上。这样做之后对市场反应的速度会远超他人。如果真的发展到某一天，云服务满足不了业务需求时，因为云服务已经划分清楚了明确的边界，所以在此边界内自主实现相应能力是一个收敛的问题，所以完全可以自己根据业务建设边界内的基础能力。    

如果创业公司一开始从零开始完全自主建设所有能力，很可能造成边界的蔓延，比如一部分本来应该在数据层的能力放到应用层中，AP的数据放到了TP来实现等等。这些蔓延最终会表现为隐性的耦合，从而大大减少了技术架构的生命期。 

云服务有一个非常明显的特性，他会将底层能力与上层应用切割，同时将通用能力与具体业务逻辑分开，所以在未来开发中，很适合我们创业团队根据业务的需求去快速搭建自己的系统。我们现在的架构如下：

(点击放大) 

整个架构大致有三个部分，数据中心，云基础设施和上层应用服务，我们先来看看数据部分，这是一切的起点。

数据来源：

最下面是底层可以收到的数据来源，大概有三种类型的数据源支撑我们现在的数据服务：第三方自有的平台，公共的电商平台和公开的信息平台。第三方自有的平台是类似于我们所服务的顺丰，杜蕾斯，Nike等企业自有数据系统。公共的电商平台就是淘宝，天猫和京东等主流电商平台。公开的信息平台包括百度贴吧，微博和新闻类网站等公共信息门户。

数据采集：

我们通过十几个，几十个数据采集服务，把这些原始数据采集到数据中心。数据采集同时也承担了数据清洗和格式化的工作，这对于数据是否可以顺利进入数据中心非常重要。

数据中心：

包含了OLTP层，ETL层和OLAP层这三个数据加工层级。还包含了特定场景的数据分析引擎和特有生态的数据服务。这是最核心的一部分。

在OLTP层，我们将高结构化数据存入关系型数据库集群，这里得益于阿里云的DRDS的支持，使得数据的水平Sharding变得特别容易。同时我们也会把低结构化数据存储在阿里云的Nosql产品中，我们是用了OCS, Redis, OTS, MongoDB四款阿里云的Nosql产品来应对IO要求和结构化程度不同的各类数据。

在ETL层，我们将加工数据的逻辑写成一个个小的加工服务，配合数加IDE便捷的配置管理，与ODPS几乎无底洞一般的大数据运算能力，将OLTP层的数据加工为可供上层业务系统使用的数据形式。

在OLAP层，我们分别面对在线分析和离线报表两种场景。对于在线分析，我们分别使用ADS，ODPS ，RDS，ARMS和部分Nosql产品来组和解决不同的在线分析场景。ADS对于数据结构和查询方式清晰的场景非常强大，但是灵活性不足。ODPS可以预算一部分数据，配合ARMS的流计算能力可以获取更大体量数据的实时分析。RDS和Nosql在部分中间计算的时候也非常有用。对于离线分析，基本依靠ODPS和数据同步服务来完成即可，已经是非常方便了。

数据分析引擎主要提供特定场景下的数据分析的服务。我们是用了公众趋势分析来对品牌的市场舆情做分析，提供给客户关于品牌的最新反馈和决策依据。推荐引擎在我们的主要客户，零售企业来说非常有用，直接关系到是否提升销售额。希望阿里云在这方面还能提供能多的场景能力。

特定业务数据中心我们目前用了一部分，但还不全面。主要在给客户提供技术方案时可以大大增加接入的宽泛性。比如客户在一定的数据量内，Petadata可以提供一揽子的解决方案，大大缩短了开发的周期，减少了给客户提案的难度。Greenplum数据中心可以给原来就是GP生态的客户提供接入的可能性。金融数据中心目前我们只有一家客户有这个需求，还没有确定，但仍然给我们提案提供了可能性。

Daas API：

我们通过阿里云的API服务，将数据中心的基础数据与加工数据，通过1.数据维度，2.业务为度，3.调用维度三个方向进行切分，然后通过API透传给我们的各类合作方。这里有一个可公开的例子：http://open.wangjubao.com

 

(点击放大)

有了数据后，我们就需要开始基于数据的业务应用的开发了，所以来云基础设施部分，他有效的支持了上层应用的开发。

微服务中间件套件：

这是我们基于云开发应用服务的核心。我们原来使用Dubbo作为我们服务化的框架，目前正在往阿里云的Edas迁移。图上是基于Edas来画的，也算是对于未来的预期了。

服务化对于需求高度变化/不确定的业务领域特别~特别~特别~重要，强调3遍。因为服务化是我们技术团队实现大中台小前台的唯一道路。大中台就是基础的，通用的，具备一定抽象的各类能力的一个功能池，他给上层的应用的，独特的，需要落地的各种小前台能力提供了基础。这使得我们的业务拓展变得非常快。云服务作为最底层的基础设施是一级火箭，基于服务化构建的大中台就是二级火箭。云服务推动大中台的快速产生，大中台就推动小前台快速试错、实践、实现各类市场的需求。

哦，为什么服务化是唯一道路？因为服务化提供了“边界”，这种边界不仅是静态工程的边界，也是运行时服务的边界。基于服务的边界，我们可以在大颗粒上组合我们的抽象能力和具体能力，形成最终的大中台，小前台的架构。Edas提供了Dubbo需要自己实现的服务拓扑、调用链、调用统计等使用服务化的重要功能，值得一试。

与服务化相关的不仅是Edas提供的微服务的实现，还包括灵活的底层设施和虚拟化。ECS我觉得已经不需过多介绍，配合弹性伸缩可以非常好的应多系统强度的起伏与扩展。Docker的提供使得部署于调整变得更加方便。其他一些比如网络的弹性扩容，专网可接入等特性，使得给客户提供方案时特别灵活，也增加了我们获得市场机会的几率。

对于我们这种提供数据服务的团队来说，数据的分发与定时数据分析任务的执行是非常常见的。阿里云的消息队列产品使我们基本上不怎么需要关心数据分发量的问题，更不需要去担心宕机的可能了。任务调度产品是我们基本不用担心会不会任务没有定时启动的问题，这也是我们原来自己使用定时任务最担心的事。

开发套件：

我们使用了阿里云的3个产品来支持我们的开发工作。第一个要说的是阿里云持续交付平台（CRP）。这个不仅是一个代码托管平台，也是可以自定义进行开发的整个代码生命周期的管理平台。我们在CRP上开发了文档自动化、代码质量自动检查、异常数据扫描、提交人责任管理等，用于确保每一次代码提交都被监控，代码来源可追溯（菜场的猪肉也这样……）。对于团队的开发人员来说，只需要提交代码->看最终检查结果->决定是否可上线，即可。让工程师把脑力集中于业务逻辑和代码逻辑的统一，也是我们团队竞争力的一个关键。这里有一点可公开的资料：http://guide.wangjubao.com

第二个要说的是阿里云的日志服务。日志是监控系统运行时的重要手段，但还不是最佳手段。监控的最佳手段在于“具有语义的表达”和“合理触达干系人”。在表达方面，最原始的手段就是看log，这是一种只有技术人员甚至只有该代码的开发人员才看得懂的监控信息。高级一点的可以做到图形化，利用“时态”、“分层”等可视化手段来表达当前系统状态，这确实更容易理解，但是也需要对系统和业务有相当程度的理解。最佳的做法是将系统状态通过“语义性”的描述直接表达出来了，比如：“提示：A服务的负担过高可能需要扩容。判断原因：72%的API的响应时间超过标准值，且已经连续7天的。详细信息：（过去7天的响应时间的时态图……）”。用能听得懂的话表达出系统状态，这样无论是技术还是客服或产品都可以基于监控信息来获得更好的结果。

阿里云目前提供的日志服务可以积累最原始的监控信息，然后我们利用阿里云的ARMS来加工部分原始信息，特别是性能统计类的信息，最后结合数加的Datav来做到图形化。可惜的是Datav目前对于拓扑类的图形表达支持还不好，而且阿里云也没有提供任何基于日志数据产生语义信息的工具，我们得自己做。

在触达方面，我们需要把监控信息传递给最需要最能解决问题的人。找人方面，我们结合上面第一点的CRP，对每个服务的最近提交人做记录，一旦这个服务产生了任何需要人介入的问题，在技术上可以立刻找到他。同时我们还配置了服务的客服和产品的关联关系，对于监控信息可以触达到不止一人。做到先于绝大部分客户发现问题。触达方面我们用了阿里云的短信和语音服务。对于高优先级的信息，我们是用语音单播来最大可能触达到相关人，低一些的我们用短信和邮件来触达。阿里云的短信和语音价格上优势不明显，但是触达率还是不错的，对于不高频的监控信息的触达效果不错。

最后一个就是阿里云的DMS，这个在做基础数据开发时很有用。我不知道多少人在遇到慢sql的问题后，自己用代码写过统计。DMS可以非常直观的表现出SQL的执行状态，会话的状态，最关键的是他可以根据需要生成诊断报告。这对于数据库人才储备不足的中小团队来说非常有用。在DMS的帮助下，数据开发可以省去发现问题和调查问题这两个耗时耗力的步骤，简化了与数据库有关的工作。

运维套件：

我们团队虽然人不多，却需要支持上千家品牌客户的数据需要。运维资源少和支持客户多的矛盾一直都是存在的。阿里云提供了多种与运维有关的产品，一定程度上缓解了我们运维资源不匹配客户数量的矛盾。

阿里云的ROS对于我们的独立部署客户是最有用的。当客户提出需要完全隔离的数据和权限环境时，我们就会推荐独立部署的方案。我们针对不同体量和需要的客户，在阿里云的ROS上创建好模板，真正需要部署时只需要稍加调整，就可以自动部署完各种云资源以及配置。这样的操作程度，使得我们并不需要特别专业的部署人员，而是由部分开发人员即可完成部署，对于我们这样的创业型团队来说，提高了生产资源的利用率，也就是提高了竞争力。

阿里云的云监控目前看来，有点用，但又觉得最后一公里没做好。对于我们这样已经在一个行业深耕5年多的团队来说，阿里云的云监控反应的基础设施的指标，远远不能表达出系统的问题。基础设施的指标只是系统状态参考的1/10大概。我们自己基于云监控的SDK结合日志服务，再自己写了一套监控系统，才满足了我们的需求。云监控不能接入其他的数据并且结合后来显示和报警，这个问题是需要解决的。

权限控制很简单，我们用了这么多云产品，不可能都是一个账号去配置管理的，所以RAM是必须的。但是RAM一直存在覆盖不够全的问题，这也给我们这种深度云用户带来了麻烦。很多的公测内测产品都不支持RAM，使得我们的主账号仍然有暴露的风险。

业务监控就是之前提到过的ARMS。我们把阿里云的日志服务中获取的部分性能数据在ARMS中做实时的聚合，然后配合Datav显示出来。这个就不重复说了。

全链路安全套件：

阿里云的安全产品很多，解决的问题也各不相同，从图上你可以看到从网络——传输——服务器——应用——内容——业务——整体，从下到上几乎每一层都有相应的产品进行安全保障。我有一次很深的印象，当时我们的产品为了快速获取流量，在百度上买了其他多个竞品都买的关键字。才过了1天，这个产品的官网就遭到了攻击，基本瘫痪，流量投入的钱不仅没有起到效果，反而让人觉得这个产品是不是已经没人维护了，连官网都打不开了。我们团队并没有安全领域的同学，当时真是傻眼。后来赶紧和小二联系了一下，推荐我们升级了安骑士以及购买了web应用防火墙。接下来就在管理台看到来自xxx的攻击xxx次之类的各种信息，而我们的网站也再也没有发生过被攻击不能访问的状态。当时心想要是自建的服务器不知道要怎么办了。

我们目前主要使用了安骑士增强版、web应用防火墙、移动安全，绿网和数据风控这几个安全产品。高防IP、加密服务和态势感知这几个产品业务上还没有需求场景，所以并没有使用。但是架构图从完整性和对未来的预期考虑，仍然标注在图上，以备日后完善。

 

(点击放大)

当数据的需求得到满足，应用的基础设施也得到支持之后，我们就可以开始跟据业务需要组建我们的整个服务和应用产品群了。 

数据分析服务：

数据分析服务主要是指所有涉及到数据的关联、聚合、转义、钻取、切片等的独立服务。之前也说过，我们的数据中心具备TP、AP、部分AI的能力。这部分数据分析服务非常依赖于数据中心提供的整体能力，这也是我们大中台小前台的一个最好实践。图上只列出了很少一部分服务，这样的服务实际上存在上百个。

数据应用服务：

这部分服务主要对应OLTP的场景，强调交互简单、响应速度快、易于理解使用等与体验有关的指标。从图上可以看到，记录管理类的服务很多都是数据应用类的服务。这部分服务更多的会依赖于云服务基础设施的能力，对于数据中心的应用大都局限于OLTP数据库的那些产品，比较单纯。

Saas应用：

这部分值得一说。从图上看起来，许多的服务组成了最终的产品，这没错。但实际上，基于我们的小前台的突飞猛进，我们的产品其实已经是一种模块化的状态了。我们可以根据客户实际的体量需求、安全性需求、功能需求、性能需求等交付相同却又不同的产品。大大增加了市场同学的应对能力。可以说，没有阿里云的数据产品和服务基础设施，我们就无法用比较低的代价，构建出一整套大中台小前台的灵活系统，也就无法灵活地争取市场的机会。

Paas API：

当客户具备一定的自主技术能力时，可以根据我们的规范，直接调用我们各种服务的接口。这就给客户解决最后一公里的各种细节问题提供了可能。虽然我们的产品是足够灵活的，但是当产生各类跨出原有领域的需求时，我们是无法直接把这些需求产品化并提交给客户的。这时候Paas API就可以很好的承担这个作用，无论是客户本身还是领域的合作方，基于API可以实现数据与应用逻辑的互通，使得解决更深层问题也变得可能。

其他：

我们还有一些营销服务和合作商，但这方面与阿里云关系不大，在此就不赘述了。

 

成果

这么说吧，我们公司现在公开的5个产品（参照：http://www.wangjubao.com）。技术上总投入资源大约是同类产品的1/5。你可能很难想象我们这样一个中小规模的技术团队，可以同时支撑5个产品，而且这还仅仅是公开的市售的标准产品，还不包含定制开发、合作开发和独立拆卖的产品。而我们的客户，已有3000多家品牌了。国际上包括：Nike、哥伦比亚、狼爪、Northface等。国内有佐丹奴、意尔康、丽音坊等。还有像顺丰海淘、美美箱这种纯电商。此外还有零售、快消、线下服务业、金融等各个维度的品牌。

所以你也知道为什么我一直会强调之前架构的大中台小前台结构了吧。

 

更多

作为阿里云的深度用户，我们对阿里云其实有更多的期待。比如：云监控是否可以和自定义数据结合？日志服务是否可以加入语义配置？RDS对于数据库版本更新能否更快响应？ADS对于数据结构支持能否更加灵活？算法平台能否增加更多使用案例？Edas能否提供图形化调用监控？Datav是否能更多的增强拓扑的表现能力……等等。

人总是很贪心的，简单之后想要更傻瓜，自动之后想要更智能。但无论如何，背后的业务问题都需要自己解决。云服务会将所有人更往前一步推向业务问题的解决，我想以后业务架构师这样的角色也许会越来越多。

作为云计算时代的技术从业者，我觉得我们需要尽早开始习惯左手业务建模，右手技术建模，双手合并解决问题的“新日常”。特别是应用开发人员，一定要往前一步靠近业务，因为价值网络总是会往更高效的方式去走，云计算的兴起，势必降低了自己做底层基础建设的价值。如果对于底层技术感兴趣的话，最好就是加入云计算的供应商，那里有成千上万的案例来考验你的基础设施的开发能力。

       创业者都会问：“团队规模这么小，怎么去和别人竞争？”在云计算时代，我想已经有了答案。网聚宝的实际经验是：上云，至少在技术生产侧，可以提供10倍的生产力。《孙子兵法》：故用兵之法,十则围之,五则攻之,倍则分之……共勉！

上海云贝网络科技有限公司

首席架构师     刘立兼