从Docker的转变，谈容器生态与微服务的发展

编者按

容器技术目前已经成为技术圈内的“常识”，但是容器生态能否健康发展仍然任重道远。在收获最初的赞扬之后，领军者Docker如今身陷非议：今年执意壮大发展Swarm进军编排领域，似乎Docker公司一方面惹毛了很多强劲的编排领域玩家，另一方面也并没有收获预料之中的成果。12月14日，Docker计划将其关键容器运行模块之一Containerd贡献给开源社区。在周晖先生看来，这意味着Docker的重心将回归到容器技术本身，或已放缓其在编排领域的步伐。一直从事PaaS和容器技术研究的周先生还认为，不管怎样，Docker都是一家有着特色的优秀公司，Docker成功地将容器技术理念深入人心，并且也增加了业界对PaaS的认识和信心。以下文章来自于InfoQ对Pivotal大中华区云计算首席架构师周晖的采访整理。

嘉宾

周晖，Pivotal大中华区云计算首席架构师，有着丰富的PaaS云实际建设经验，负责过国内某知名银行已经生产上线一年的PaaS云的架构设计和部分功能的实现，参与过某超算PaaS、某超市电商PaaS、某电力PaaS等项目的建设。

诞生与兴起：Docker赢得声誉

容器技术被传颂并深入人心，是因为Docker；但是，其实技术积累由来已久，早期的容器技术是Google、IBM等公司贡献出来的，Pivotal也发展了Warden容器技术，这些公司都专注于在各自的常规业务中，并没有重点投入容器技术；而Docker很好地将容器技术单独形成项目产品推向社区。

为什么有同样技术潜力的公司，会有如此迥异的产品决策？我认为是因为着眼点不一样或者说基因不同，大公司着眼于规模化的企业应用，比如Pivotal把容器技术内置在PaaS技术中，然后以完整的解决方案的形式提供出来。结合自身例子来看，其实Warden比Docker早，但是Pivotal从成立的第一天起，就是面向企业级的，产品代码模块很完整，Warden容器的代码量很可能少于整体Cloud Foundry的千分之一，单独拿出来对企业客户意义不大，并且目标客户也不需要知道那么底层的技术细节，他们需要更专注于业务创新。

而Docker公司具有开发者基因：Docker的产品很适合开发者，快速升级以满足新的功能需求，完全不用管和前面版本的兼容性，就像有故障重启Windows那么简单，但是你让客户去重启他们生产系统的Linux就不会那么轻易了，并且Docker对开发者简单易用。Cloud Foundry提供的容器是黑盒子，对运维人员来说简单易用，无需关注容器细节，甚至都不需要直接操作容器；而Docker是白盒子，随意增添组合特性，对于技术fans很有价值。同样Docker也有很多很棒的设计，举例说明，镜像仓库，谁都可以把自己做好的Docker镜像上传上去，目前Docker的镜像仓库有海量的镜像，这符合互联网的分享精神并因此发展壮大。所以Docker之所以发展起来，可以说他摸到了市场的脉络。

因此除了自身优秀和容器界技术成熟之外，另外一个因素是Docker生逢其时。2013年Docker诞生之时，正值企业应用转向互联网应用高速发展时期，应用小型化微服务化的需求正好是其用武之地，也就是适应了今天流行面更广的微服务的一个方面---应用部署到容器中运行。

变形发展：急于盈利，引起生态圈的利益冲突

Docker在2016这一年做了让生态圈反感的事情：通过之前收购一些公司大张旗鼓地发展Swarm，集中发力集群编排管理。

容器生态中有两个领域：一类是容器本身的领域，另外一类编排集群管理领域。这两个领域虽然会有重叠的部分不完全独立，但是基本上各有各的发展方向，靶向用户不同。

第一领域是Docker最开始在做的内容，面向开发者、小型企业或者个人版尝试测试，直接应用在大型企业中的还是比较少，最多是一个部门级别的应用（数量级一般为个位数）；用于开发和测试，在生产中用的比较少（设计时也没有考虑到生产的复杂性）。

第二领域的领军代表是Mesos、Kubernetes和Cloud Foundry，或者说现在的CaaS。在企业中的应用，这个派系更适合做成云，管理的是大规模的应用运行生产环境。

两者的定位是不一样的，但是第二类集群管理具有更多、更早的盈利空间；经过多轮融资后的Docker Docker对盈利愿望比较强烈，因为容器本身开源很难挣钱，都是不掏钱的客户，所以希望打入企业级的容器集群管理市场来盈利。可是Swarm等一系列举动被视为捆绑竞争，非但没有让人对其技术刮目相看，反而损还他与生态圈内其他厂商的关系。在今年7月底，GoogleKubernetes布道师 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上发生了激烈争论，争论的主题是要不要用RunC或其他容器来取代Docker引擎以及OCI的意义。

被迫妥协：共同研发的RunC意味着什么？

Docker一开始就一家独大，并且并不是一种开放的态姿态在做，所以很早之前Google就投资了CoreOS来做竞争的容器--Rocket。那时是三家鼎立：Docker/Rocket/Warden，为了避免惨烈的竞争，大家终于统一意见，决定成立OCI做统一的容器运行时---RunC，OCI成立后加入了大约50家厂商。出于对Docker封闭化商业式发展的担心，OCI商讨出这种方案：以RunC为核心重新构建生态圈，并且通过插件来弱化容器在CaaS生态圈的重要性。

OCI负责的RunC是非常小的运行核，其目的在于提供一个干净简单的运行环境，他就是负责隔离CPU、内存、网络等形成一个运行环境，可以看作一个小的操作系统：现在OCI只负责这些，尚未扩大到更大的范围，其实这样是小而美的，这样的是业界所最需要的。

当然， RunC的生态发展就会局限在企业级别应用中，并因此具有不同的发展目标：RunC不是要提供多少种工具，而是要非常稳定。接下来需要做的是可能是添加完善一些功能，比如将Docker镜像导进来，与各种插件更好地结合（动态化即插即用），热启动和迁移。这些功能是企业需要的，但是对开发者没什么作用。以热迁移为例，从一台虚拟机迁移到另外一台虚拟机，但是开发者可能本来就一台机器并没有这个需要。

因为RunC是Docker的一个子集，所以单纯从代码量上来讲，RunC只占Docker的百分之几。

相比而言，Docker有丰富工具，更贴近于开发者。这也是为什么很多个人开发者并不知道RunC，因为RunC的使用者都是Mesos、K8S和Cloud Foundry这类的CaaS厂商。

在RunC早期，Docker是主要贡献者（在我看来，如果Docker不参与RunC的发展就意味着和容器生态圈决裂）；后来随着各大厂商对RunC大幅贡献代码，RunC的代码贡献者越来越多样化,Docker所占比例在持续下降。通过不断迭代，RunC一定会越来越成熟，它已经在生产环境中开始积累技术了，Cloud Foundry已经有不少全球重量级客户在用内置RunC容器，经历的很多坑的bug修补已经回馈到RunC源码中去了。

Docker的运行内核虽然是从1.11支持RunC的，但是Docker的心态是很复杂的：一方面作为OCI成员必须支持RunC，但是另一方面他会担心RunC对Docker的替代的威胁。

危机解读： 适合Docker公司的路在何方？

坦率而言，我认为Docker进军编排界并没有优势，因为他缺乏企业级基因。

Docker更适合在容器本身的技术，今年Docker力推Swarm，把资源花在了集群管理上，这其实并不是Docker技术的初心。当时Docker迅速流行是因为简单易用，而后来走却想把太多东西塞到Docker中。

在从目前适用场景选择来看，一般而言，使用Docker Swarm的都是小企业的小规模应用，而大企业采用的都是Mesos、K8S或Cloud Foundry。（当然有极少的案例采用了Docker的Swarm，但是从比例而言这并不具普遍性）。因为最初的设计来源就不一样，前者是从开发者角度设计，而Mesos、K8S和Cloud Foundry是从企业中来，有很多企业运维的实战积累。

Docker也就是小几百人的公司，并不算巨头公司，做企业级市场比较吃力，而做中小企业或是个人用户市场这种思路更适合Docker的盈利模式。在我看来，不论国内国外，做企业级市场一定需要很多销售去和企业用户打交道聊需求，项目实施的时候往往要根据客户的需求做定制，要知道每个企业用户的需求是不一样的，没有办法进行完全统一的标准化，那定制化的需求就需要一定规模的人力投入，每个项目都需要一定的人员资源投入，小公司很难做这种投入。在我看来，小作坊做企业用户还是面临很大的挑战。

从企业级需求来看，比如企业一个考虑就是，一定要前后版本兼容，否则就无法升级。而这恰恰是Docker不care，比如个人用户可以随时重启机器，开发者在遇到问题可以重启，在企业级的思路不是这样的。Docker的思路并不是做企业级IT应用系统的思路，所以如果应用到企业级应用中一定会遇到问题。至于很多互联网公司在应用Docker，很多互联网公司也是在摸索，包括自己做Docker集群管理的不少，但自己做Docker集群管理的基本都开始开始转向K8s、Cloud Foundry、Mesos这些专业的容器集群管理软件了，这是很明显的趋势，那么这些互联网企业当初花资源做的集群管理基本就是被废弃，即使现在没转的迟早要转型到CF(Cloud Foundry)/K8s/Mesos。对于企业客户来说，这种试错是得不偿失的，因为企业客户没有这么多人去研究开发容器集群管理软件。但对互联网公司来说，这个试错是可以接受的，毕竟养这么多工程师其中有一部分就是通过不断的、或大或小的试错而优化技术的。

Docker为什么最初发展那么快，因为是面向开发者，个人用户或者中小企业，这是他兴旺起来的市场。起步于个人消费者市场，却又想立刻切入企业级市场必然会有很多水土不服，这种背离最初的起源的做法并不是很明智，我认为面向个人消费者其实才是Docker的固有基因。

那怎样才是Docker更好的盈利模式呢？在我看来，Docker可以在镜像仓库上发力，做成类似苹果AppStore的模式。Docker的优势在于他有镜像的入口(互联网最关注的几个价值点之一)，他应该把镜像市场运营好，第三方在使用镜像的时候进行付费。比如MySQL镜像，网上不说一万种也有一千种；但是哪个镜像好用还真考验用户，如果用户用的不好，也没有反应并改进的渠道，其实这样也不利于MySQL镜像的持续发展，如果Docker能够对自己仓库市场的高质量MySQL镜像收费，然后分成给做MySQL镜像的公司，做MySQL镜像的公司也可以根据客户的反馈进行不断优化，做到生产可用；那么用户应该是乐意付租金费用的，毕竟自己花费成本做一个生产可用的mysql镜像成本不低，这有很大的经济价值。Docker可以与MySQL等厂商进行利润分成的模式扩展，就比较容易盈利了。

迷途知返：Docker公司重拾初心？

经过激烈的碰撞，现在Docker又回归到自己擅长的老本行中，将视线从编排界收回到容器技术。

1 Containerd的开源

12月13日，Docker 开源了Containerd( https://containerd.io )，它是为RunC提供接口并进行镜像的管理。非常有意思的是Docker没有把Containerd贡献给Apache/Linux之类的基金会，或是直接贡献给RunC，而是单独开源，这个态度很是微妙，体现了对RunC一定的防范，目前有AWS、Google，IBM、Microsoft和阿里云等作为初始成员，会为项目提供贡献和维护人员。 我对这个举措解读为Docker对容器技术的回归，并且是对16年争论的折中，他希望生态更加开放，更良性的发展，降低业界对Docker封闭的担心，同时也是通过Containerd作为桥梁，让大家更多地关注回Docker，抵消因为生态分裂对Docker带来的不利影响。

在我看来，这其实也不失为一种对RunC的堤防措施，让大家在使用RunC同时也不忘记Docker；开源的举措也可以一定程度缓和关系（不过，我认为Docker并不会把Containerd交给RunC方运营）。

2 DataCenter“钱”途未卜

今年年初的时候做了DDC（Docker Data Center），其目的是为了向客户收费。但是，目前无法找到这个项目的营收数字，单从DDC和Docker开源部分来说，没有太大的差别，商业价值还无法确认。

3 与阿里云合作 的全面合作

Docker选择重量级的公司合作其实是一个明智的选择，虽然这对做Docker镜像仓库公有服务的小公司确实不是好消息。大公司的好处有人力和财力，而且Docker的商务版(DDC)未来要放在国内公有云上，阿里有这样的基础设施，可以在初期承受大量客户免费试用的投入，在IaaS公有云生产级别也更可靠。

当然，有人欢喜有人忧，此番合作还意味着：Container as a Service公有云的市场就已经定型了，做Docker镜像仓库公有市场对创业公司关闭了。

4 Swarm还会继续，但前景不明

Docker还会把Swarm继续支持下去，但是编排领域的有很多细分的市场，Swarm的发展目标应该会是小规模的集群；而且Docker的发展重心还是会回到容器本身，因为只有精专容器本身技术，才会凸显Docker独特的优势。做编排的话，从社区热度、贡献人数、发布频率可以看出，Swarm应该是会被其他竞争对手的光环所淹没。

Docker重新考虑在做的就是扬长避短：既然短处不能补成长处，那么就需要回归继续发扬长处。

避免竞争误入歧途，容器生态仍有蓝海

上文提到了Docker与阿里云合作对国内一些创业公司造成了影响。我还想谈谈我对容器创业的一些建议：首先我不认为在Docker之上进行定制出CaaS是有市场做法，创业公司如果一定要局限于Docker创业，可以考虑在Docker生态圈中，还有那些技术空白点，然后专攻一点成为特色（这是国外容器创业公司常见的做法，Docker也收购了很多此类的优秀公司）。

那么容器生态的创业还有哪些蓝海领域呢？除了上文提到的容器类技术和编排集类，其实还有插件技术，这可以看做是两者的交集部分。插件技术是很多样化的，比如网络、存储，并且有很大的发展潜力。容器的各类插件在2017年将会有较大、较快的发展，这块目前还属于拓荒地带，经常可以看到技术进展，比如存储插件就超过10类，而且很不成熟，如果能做统一化或是成熟后、简化，都可以成为很有价值的技术。以网络插件为例，Docker有CNM标准，CoreOS、Mesos、Cloud Foundry有CNI标准，当然这两种标准从技术上讲还是有很多不兼容的地方，接下来的发展是兼容还是统一，还是一强一弱导致弱势方自然淘汰，需要走一步看一步。而至于存储，目前主要由很多存储厂商主导，根据自己的存储特性研发的存储插件，种类多且复杂，在何种情况下使用何种插件很考验用户对存储插件的理解能力。这些外围的插件还有较大的发展空间。

容器集群也还有很大的发展空间，集群的概念和应用集群微服务化刚刚兴起，在实际生产中会发现还有很多问题需要解决：比如功能尚不完善、可靠性和稳定性有待提高。

那插件为什么目前还不是OCI标准所关注的呢？OCI目前关注的是RunC，以一个更小的核心给业界；而插件是RunC补充，提供了很好扩展方式：RunC作为运行环境，很多环境是不需要插件就可以运行，比如大部分的Java/Web微服务应用，反倒是传统应用容器化，需要用到插件，但这类应用并不是容器化的最主流应用,是典型的1：9现象。就是90%的容器应用不需要插件，10%的应用需要插件，但是插件带来相当大的复杂性。应用容器化只须在需要哪种功能时就使用哪种相应的插件即可。不过目前各个厂商对插件的定义和理解并不完全一样，除去共识的网络、存储等插件，其他的尚模糊。比如Docker对插件有自己的理解，哪些是插件，是否放到运行环境里面；Mesos对插件的解读范围就更广，所以将插件标准化的想法在我看来还是不太容易。

但是，对于网络插件，业界认识都比较统一，因为是普遍需求，并且应用的多是VPN隧道技术。如果对这类插件进行统一标准化，可以便于相互之间的通用。

另外，为什么不建议小型创业公司考虑企业级的完整版CaaS？和Docker的情况类似，这需要有企业技术经验积累、规模化人力和财力的持续投入。举个例子，在某次竞标，一家银行在招标，当时的要求就是厂商可以自我证明可以存活三年，说明企业客户对创业公司能否存活三年还是有疑虑的。

Docker兴起，推动了PaaS的推广

Docker到来前，PaaS主要在企业级市场，并不为公众所知。PaaS分成公有云和私有云市场。国内公有PaaS云市场的很多厂商基本上成为了先烈，主要问题在持续投资无法实现正向现金流，因为彼时PaaS主要面向开发者，向开发者收费有难度，而向开发者/中小企业提供IaaS的市场则发展比较好。不同的是，国外最早Heroku 、Salesforce等在做公有云的PaaS比较成功，在比较长时间的实践中积累了很多PaaS的模型和经验，后来Cloud Foundry当时也吸取了当时两者很多很好的实践经验。

Docker的流行促进了大家对PaaS的认知，当然也有了CaaS的兴起（如果进行更严格的定义的话，Docker是属于CaaS的），把PaaS从企业级市场的认知扩展到了开发者市场。很多人是先接受并理解了Docker，才开始关注思考PaaS。这是因为PaaS只是针对企业级用户，很难形成普遍的知名度；而Docker是面向开发者的，开发者使用了Docker之后向团队推荐，团队再向上层同步信息，是一种自下而上的传播。

私有云市场的PaaS最早是互联网公司在无意识的做，后来Pivotal进入市场，逐步定义了PaaS完整的架构，我们最早的商业客户是在2013年底，那时Pivotal需要向客户从0开始讲解私有云的概念，而现在对于技术fans的客户，只需要说PaaS是在Docker的基础上做了那些技术工作即可。

放眼未来，PaaS和CaaS可以各自辉煌

PaaS和CaaS两者有重合的部分，但是也有不同的侧重：CaaS是提供一个容器，里面是跑应用跑数据库等都可以；而PaaS更关注的是应用，要对应用进行监控，要有应用框架、通用的应用功能如Session集中管理、日志服务、路由服务等。

PaaS通过构建包来一键部署应用，这样的做法极大的简化了应用的安装部署，也是遵循DevOps的理念。相反，Docker让开发者去写复杂的脚本部署应用，比如目前DockerFile和Docker Compose，这对于开发者而言很痛苦乃至不可行的环节，这要求的不是业务编码技能，而是对应用服务器、对操作系统脚本的编程技能。CaaS不限于应用平台，它也不专注于解决应用平台问题，所以它也不善于解决应用平台的问题。

和CaaS不同， PaaS（Heroku、Cloud Foundry等）把应用相关的复杂度屏蔽，只需一键部署应用即可运行起来，无需关注应用环境的安装环节，还有应用故障自动恢复、自动弹性伸缩、灰度发布等使得应用运维可以全自动化。回到Docker而言，其实它对DevOps仍然有一定难度：Dockerfile/Compose的书写一般是运维人员在做的事情，而Docker镜像打好了需要交给开发人员，并没有办法做的很完美，很多地方没有办法完全固定，比如开发人员发现需要更改一个应用服务器的端口这么简单的一件事情，这可能就涉及到一系列的脚本的改写，但这个事情到底是运维人员来做还是开发人员来做？运维人员来做那就不是DevOps了，如果开发人员来做，开发人员又很难具备运维人员的脚步编程技巧。而这一点Heroku和Cloud Foundry已经注意到了，并通过构建包彻底分离了运维人员和开发人员的分工。

我们看PaaS/CaaS的区别和各自的市场，PaaS的思路基于应用平台，而CaaS并不限于应用平台，因此它也并不能理解应用平台的问题；所以两者面对的市场还不太一样，如果着眼于应用平台那PaaS比较好，如果是希望把各种资源管理起来，当做虚机使用，通过容器实现，那CaaS比较好。

关于Docker和微服务

我认为将Docker等同于微服务是一个误导性的看法。 微服务由两个组成部分：运行环境（运行于容器中是很好的运行环境的选择），开发框架（比如服务动态注册、发现和调用等）。业内很多人只重视到了第一部分，而忽略了第二部分，比如Docker微服务化最常见的就是微服务的动态发现和调用则几乎完全依靠第三方平台来实现，如ZooKeeper、Consul等，但是这些工具的缺点是当集群达到一定量之后就会出现不稳定的问题，而且平台要适应各种代码需求有困难，我认为程序的事情归程序来解决，而不是平台。最佳实践是采用程序框架从根本上解决问题，比如Netflix就进行了彻底的改造，他们的服务注册、发现、治理、限流都是通过程序框架(也即后来的Spring Cloud)来实现的，经受了大规模的应用考验。用平台解决代码层面问题是有缺陷的，因为平台解决的是平台问题，不能包揽代码的工作；代码框架是解决代码的问题：服务注册发现更适合在代码层面实现。

当然，微服务还有一个更关键的问题：如何对服务进行合理的分解和定义，不是说巨石应用随便按模块拆分就可以了。经常会有人问，微服务对业务进行升级以后多个模块如何一起部署，问这个问题就是微服务没有做好，学了微服务的形，没有学到微服务的实质，最终微服务的效果也会大打折扣。问这个问题的根源在于微服务解耦的不好，没有遵循微服务分解的方法论。如果微服务分解的好，那很大程度上是可以单独部署而不会影响其他模块。

微服务做好了以后怎么运维？故障发现、自动恢复，根据业务请求量的弹性伸缩等等这些工作，要么通过PaaS去自动实现，要么自主研发实现，但是这样工作量很大。最终，微服务的价值在于让开发人员只关注业务逻辑代码，不用关注非功能性相关的技术问题，这些技术问题交由微服务框架和运行环境来解决，而且微服务最终要能通过平台实现运维自动化，就是未来的热点“NoOps”，目前的ServerLess，Serverless不是目的，目标是NoOps。前几年谈NoOps，大家总觉得太遥远，其实PaaS+微服务，使得NoOps越来越近。

下一个技术热点： 数据微服务

容器是2015年最大的热点，但是2016年容器的热度在下降；2016年的热点是微服务；2017年我认为是数据的微服务化。

为何认定是技术热点？

之所以认为数据服务在PaaS、CaaS上的框架这个会成为新的热点，是因为：首先这个技术是微服务的延续，而且是必然的延续，微服务已经解决了运行环境—容器的问题，又解决了框架的问题—Spring  Cloud和Spring Boot，下一步就是数据的问题了，而且数据服务化还没有完全成熟。其实一个技术成为热点的时候就是它的对应技术方案即将成熟又未成熟之时，容器和微服务成为业界注意力中心的时候都是这样，也就是大家对它将懂未懂，最需要了解的时候，这种状态就是技术热点状态。

以今年火爆的微服务为例，SpringBoot 很早就开始有研发；2014年以产品形式出现，但是当年月下载量是十万级别，而今年单月的下载量就可以上千万，两年不到增长百倍，这就是热点。根据数据服务化的相关开源项目在社区的反馈和贡献量来看，现在也快达到了同样的临界点。

并且，创建大数据应用仍很痛

现在做大数据应用，需要装很复杂的大数据环境。如果将其服务化，只需要点击创建即可，使用者不必关心后面 的GreenPlum、Hadoop等是怎么安装部署的。Hadoop那么多组件，一个个安装太麻烦了。

目前我们做的数据服务化的技术储备包括大数据服务化、数据服务化、流数据服务化，这三类技术正在逐步达到生产可用.。因为大家做完应用之后就开始考虑数据怎么办，数据按照传统方式来做是肯定没有问题的，但是应用微服务之后，要求数据要和微服务应用对应，原来的巨石应用分拆为微服务了，那原来的大一统的大型数据库，也要根据微服务进行拆分，拆分之后要分析数据是用传统的SQL数据库，还是新的NoSQL，或是缓存加持久化。所以我认为这个就是将来热点。以Spring Data为例，它负责数据抽象，至于最后落到哪类数据库MySQL、Oracle甚至是NoSQL类的MongoDB的技术细节，开发者不必关心，到部署的时候再绑定，这就要求数据能够服务化。

数据服务化具体的实现可能还是先从主流互联网应用数据库(比如MySQL， PostgreSQL)开始，然后逐渐覆盖各种实现，比如Redis实现、MongoDB实现等。在解决完功能问题之后，要解决性能问题、安全问题，整个就会变成一个很大的热点；最开始还是先面向开发者慢慢扩展到企业层面。

未来之路

在最开始，业内容易把云和大数据搞混，认为Hadoop就是云；后来慢慢理解其实是两种泾渭分明不同的技术。而现在，大数据的进一步发展又离不开云计算能力：大数据处理最后给哪个应用使用，如何获得大数据信息价值以及提供给谁，需要经过应用平台把大数据的能力体现出去。从这个应用的角度来看，我认为大数据应用需要落在PaaS上。另外，云有很好的弹性能力，所以云可以更好地支持大数据的弹性计算。

不过这新结合的难度要大于之前的热点技术容器和微服务，如果说这后两者解决的是点问题，那大数据和PaaS的结合则是面的问题，PaaS本身就是个很大的面。点点结合比较容易，但是面和面结合难度就会比较大，我估计需要3-5年或者更长时间才能逐步发展成熟。