标签归档:容器

容器正在实现安全性和监控功能的融合

当我大约五年前看到集装箱的出现,有一点是明确的:如果-这是一个很大的,如果那时-如果容器成为一个事情,他们会改变企业如何将生产经营他们的应用程序。

快进到今天,这个观察并不是惊天动地。容器的早期采用者已经发现了这种情况(有时很难)。更有趣的是容器和微服务架构从根本上改变了运营方式。我甚至可以说容器正在实现安全性和监控功能的融合,从而加速向DevSecOps的迁移。

但让我们退后一步。

组织正在转向容器,以简化开发并加快创新步伐。2017年Forrester的一项研究发现,在接受调查的组织中,66%的公司实现了加速的开发人员效率,而75%的公司实现了应用程序部署速度的中等至显着增长。

话虽如此,容器对企业来说相对较新。在2018年6月的DockerCon旧金山活动中,Docker指出,在接受调查的参与者中,有50%的人在去年开始使用容器,这表明大多数IT专业人员和DevOps人群仍在学习。当这些新手用容器生产时,我怀疑他们的预生产计划将包括重新考虑监控和安全流程。

我们来讨论一下原因。

容器更易于创建和快速旋转,因为它们通常比虚拟机更小,重量更轻。

95%的容器不到一周就能存活,11%的容器可以存活不到10秒。

但是,创建它们的难易程度,通过持续开发/持续集成(CI / CD)管道快速启动容器的能力,以及使用编排工具来扩展和移动它们意味着容器会被淘汰,经常重生。事实上,去年的一项研究发现,95%的容器不到一周就能存活,11%的容器可以存活不到10秒。这对开发人员来说非常棒 – 更频繁地推动代码,更快地创新,并在竞争中保持领先地位。一切都好,对吗?

没那么快。可以想象,这使跟踪小虫子的工作变得复杂。虽然容器(如果使用得当)可以改善您的安全状况,它们的绝对数量,分布以及容器的黑盒性质会迫使您重新考虑风险和合规性配置文件。将容器设置为机器或虚拟机是不明智的:由于开销,您无法在每个容器中放置代理,并且使用代码注入技术类似于在每个容器中注入病毒。这两种方法都违反了容器的软件设计原则。

在过去,您可以采用以网络为中心的方法,观察进出机器或虚拟机的所有内容,以获得正在发生的事情的“真相”。但考虑到容器的动态特性以及容器跨云移动的能力,旧的以网络为中心的方法不像以前那样工作,既不用于安全也不用于监控。

但什么可以取代网络作为真相的来源?就像容器本身是从嵌入在操作系统中的功能创建的一样,事实证明,监视和保护容器的最佳方法是利用底层系统中的一些原语。

操作系统内核可以是这样的事实:内核从不关于系统上运行的内容或这些应用程序正在做什么。这使您可以查看主机上运行的每个容器内部,让您查看所有应用程序,网络,文件和系统级活动。

因此,当然,除了您可能想要跟踪的通常混合的监控细节之外,如果您有这种类型的仪器,您还可以观察异常的安全行为并观察入侵。容器的性质简单地导致监视和安全功能的自然集成。

当然,你不必这样做,但它变得如此容易,以至于大多数集装箱商店最终会到达那里。

另一方面,全面使用微服务架构的组织别无选择,只能实现这一飞跃。

这就是原因。

微服务架构和支持平台更加复杂,因为它们隔离了功能以增加组件的分离并加速开发。开发人员和服务团队可以更自由地更快,更频繁地启动功能。并且,功能越孤立,通过将微服务组件拼接在一起就可以创建更多的排列。

然而,最终结果是运动部件数量的大量增加,以及这些应用的攻击面的巨大增加。

这是攻击者的梦想成真,也是安全专业人员的噩梦。这就是为什么微服务商店发现必须将监控和安全任务集成到他们的平台中,如果他们还没有这样做的话。

这也是DevSecOps运动如此迅速地获得蒸汽的原因。好消息是,容器环境提供了在开发周期的多个点构建自动安全扫描的机会,这应该意味着容器最终在安全意义上比甚至虚拟机更加强大。

一组强大的开源安全构建块似乎有助于解决这些容器安全问题。Anchore这样的工具解决了扫描和已知漏洞的问题; Falco解决了运行时安全违规和活动审计,并且Inspect解决了取证和事件响应问题。容器安全产品就在那里,而Sysdig等一些产品提供统一的安全性,监控,取证和故障排除,为快速发展的容器环境提供单点控制。

这简化了部署并简化了容器的管理,使组织能够从风险,安全性和合规性角度更快地移动并提高他们提供的服务质量。

根据Gartner的说法

“在应用层,不需要两个单独的工具(一个用于安全,一个用于操作)执行服务的详细监控。至少,数据将在各个团队之间共享,但理想情况下,应用程序性能监视和安全监视将合并到支持单个DevSecOps团队的应用程序监视和性能中。

容器的引入颠覆了许多惯例,并要求IT组织重新思考一切。虽然所有采用容器的组织似乎最终都会在这些环境中集成监控和安全功能,但采用微服务架构的商店别无选择,只能走今天的道路。

您应该学习微服务的十大理由

学习微服务的十大理由

始终关注新技术,语言和框架,以彻底改变您的组织。如果你仍然在你的立方体中粘贴你的整体框架中的代码,那么你可能生活在过去,你有一个小应用程序和很少的员工来处理它。现在情况发生了变化!你需要采取领先一步,并与革命性的技术在那里走路  微服务  是领导人之一。 

想知道微服务在2018年的最热门技术中的地位吗?了解Edureka的技能报告 !!

您是否正在寻找最佳理由来投入时间学习微服务以期成为架构师并使用它们来开发应用程序? 

以下是我学习微服务的十大理由:

  1. 高薪工作
  2. 使用最少的资源,降低拥有成本
  3. 促进最佳大数据实践
  4. 降低风险
  5. 提供粒度缩放
  6. 提供高质量的代码
  7. 提供跨团队协调
  8. 灵活地使用各种工具来完成所需的任务
  9. 提供持续交付
  10. 易于构建和维护应用程序

学习微服务的十大理由| Edureka

现在,让我帮助您更详细地了解这些内容。

10.易于构建和维护应用程序

当开发人员构建的产品变得稳定并且在市场上供客户使用时,开发人员团队主要分为以下活动。

  • 实现新功能
  • 修复错误
  • 更改现有功能

在这种情况下,如果产品基于单一框架,则代码库的每个更改都必须通过构建,维护和部署的所有阶段。

所以在这种情况下,微服务就像一个救世主!

易于构建和维护 - 学习微服务的十大理由 - Edureka

微服务解决了基于组织的问题,使调试和测试应用程序变得容易。在此框架的帮助下,持续交付,测试过程和提供无差错应用程序的能力大大提高。

9.提供持续交付

与专用团队为每个离散功能(如处理数据库,维护服务器端逻辑)工作的单片应用程序不同,微服务使用持续交付模型来处理应用程序的整个生命周期。

开发人员,操作人员,测试团队同时在单个服务上执行诸如构建,测试和调试之类的活动。

持续交付 - 学习微服务的十大理由 - Edureka

这种开发方法使代码能够不断开发,测试和部署。

因此,每次进行更改时都不必重新编写代码,只需从现有库中使用它即可!

8.灵活地使用各种工具完成所需任务

微服务架构鼓励使用最合适的技术来满足服务的特定需求。每项服务都可以自由使用自己的语言,框架或辅助服务。即使使用这种不同的框架,服务仍然可以与应用程序中的其他服务轻松通信。

混合技术 - 学习微服务的十大理由 - Edureka

7.提供跨团队协调

跨团队协调 - 学习微服务的十大理由 - Edureka

传统的面向服务的体系结构(SOA)涉及重量级的进程间通信协议。

但是,微服务,遵循分散化和解耦服务的概念,以便它们作为独立的实体。因此,在微服务架构中,每个团队处理各种实体,然后相互通信以处理不同的功能。

6.提供高质量的代码

遵循微服务的体系结构,完整的框架被模块化为离散组件。这有助于应用程序开发团队一次专注于一项特定的工作。因此,这反过来简化了整个编码和测试过程。

良好的质量准则 - 学习微服务的十大理由 - Edureka

5.提供粒度缩放

如果你谈论可扩展性,那么微服务就会胜过许多其他架构选择。

由于每个服务都是框架中的单独组件,因此您无需扩展整个应用程序即可扩展单个功能或服务。可以在多个服务器上部署关键业务服务,以提高可用性和性能,而不会影响其他服务的性能。

粒度缩放 - 学习微服务的十大理由 - Edureka

因此,微服务可以轻松识别扩展瓶颈,然后在每个微服务级别解决这些瓶颈。

4.降低风险

每个服务都是微服务框架中的一个独立实体,这允许本地化更改,更高的质量信任度和端到端回归方案。

降低风险 - 学习微服务的十大理由 - Edureka

因此,即使应用程序的一个服务或组件出现故障,整个应用程序也不会停止运行。相反,只有特定的服务或组件需要由开发人员重建。 

因此,这可以降低业务应用程序完全崩溃的风险!

3.促进大数据实践

微服务拥有其私有数据库来收集,摄取,处理和交付数据以实现其各自的业务功能。

大数据源 - Edureka因此,您可以说微服务与数据管道架构协作,以协调大数据收集,提取,处理和交付的方式,以微服务的形式处理小任务。

2.使用最少的资源,降低拥有成本

多个团队致力于独立服务,以便轻松部署。这种提高的微服务效率降低了基础架构成本,最大限度地减少了停机时间,优化了资源并使代码可重用。因此,在这些服务的帮助下,您不必在大型机器上运行,但基本机器将为您服务。

通过降低TCO提高投资回报率 - 学习微服务的十大理由 - Edureka

1.高薪工作

据Indeed.com称,“微服务”的平均工资范围从软件工程师每年约97,994美元到高级软件工程师每年116,027美元不等。 不仅在个人层面,而且许多超级增长公司,如Netflix,eBay,PayPal,Twitter,亚马逊在其结构中使用微服务。

我希望我的博客“学习微服务的十大理由”对你来说很重要。 

虽然它仍然处于起步阶段,如果您对这种架构很感兴趣,并且想要进行结构化学习,那么请查看我们的微服务  架构培训  ,该培训包括讲师指导的现场培训和现实生活项目经验。此培训将帮助您深入了解微服务,帮助您掌握主题。

10位技术领袖告诉你趟过的微服务那些坑和最佳实践

切换到微服务架构似乎很容易,但技术领导者往往低估了项目的复杂性,并犯下灾难性的错误。此文对来自以色列和美国等5个国家的技术领袖进行了13次采访。这篇文章很长,内容包括如下一些方面:

• 微服务是什么 • 微服务架构优劣势分析 • 微服务面临的挑战和应对解决方案 • 微服务落地要避开的坑 • 来自技术领导型企业的微服务架构最佳实践 • 如何选择微服务当中的技术栈? • 实用的技术建议 为什么转向微服务? 企业容易犯的最大错误是在没有明确目标的情况下,转向微服务架构。需要了解并有真正的理由表明为什么要这样做。

“人们盲目进入很多领域:Docker很酷,微服务很伟大!但它可能不适合你的体系构建,你需要了解为什么要这么做。” – 来自Steven McCord, ICX Media(一家企业营销视频制作众包平台 )创始人兼CTO。

如果你的系统工作正常,那有什么动力去改变它?

如果只是因为微服务被炒作,这并不意味着你需要跳入潮流。它不一定是企业软件的最佳技术选择。

“确定原因至关重要。”这是David Dawson,Steven McCord和Avi Cavale 所强调的。

“当客户要求我实施微服务时,我会问的第一个问题是,为什么?我正在寻找的答案是,“希望更快地改变系统”和“希望利用云技术”。微服务其实比建立单一的系统更昂贵和困难。微服务在数据模型中引入网络,可以随时进行任意分割,但也可能伴随数据丢失,让企业暴露在分布式计算的恐惧之中。“ – 系统架构师 David Dawson说道。 明确定义一个微服务

“我不一定选择微服务。我倾向中型服务,所以不是从单体架构转到上百种的微服务,而是与工程团队和业务保持一致的更大的服务。” – 来自 Daniel Ben-Zvi , SimilarWeb(网站和应用追踪分析公司) 研发副总裁。

如何做?一个围观案例研究

“我们通过查看哪些代码(如果更改的话)最终确定了指数测试案例,从而确定了一个微服务。我们的目标是减少对每次改变的测试次数。如果这是你的目标,那么微服务的定义就和”计费就是一个微服务”没有什么不同。”Shippable 联合创始人兼CEO Avi Cavale 说道。 微服务架构优劣势分析

微服务显著优势 可扩展性:分析小块的应用,看每块的要求,每部分可以分别伸缩应用程序的不同部分。

“另外一个好处是,可以在任何虚拟机之外扩展容器。容器可以放置在任何形式的配置中,应用程序具有完全的可移植性。“ – ICX Media 创始人兼CTO Steven McCord说道。

更简单的可维护性:不同的团队以不同方式独立处理不同的组件。

独立部署和配置:部署和配置每个服务时,不会影响其他服务。多个团队可以将多个结果投放到生产中,不会彼此干扰。

问题隔离:更容易隔离和监测问题。

易于招聘:寻找开发人员或第三方供应商时,只需培训他们系统的一部分。

清晰的责任:一个团队负责特定的微服务。

深厚的知识:团队从内到外了解相关知识。

多种编程语言:可以使用不同的编程语言,这取决于微服务的目的。

更易于监督和理解:将庞大的代码分割成更小的项目,利于团队更好地理解。

更容易开放组件:当边界和接口被明确定义时,向新的业务单元开放组件或现有功能更容易。

微服务劣势

部署和互操作性:这是首要问题。

编程语言太多:会限制代码的可重用性以及可维护性,并且维护更加复杂。

组件一起工作:要确保服务是以一种协同工作的方式组成。只考虑改变单一的端点,会打破旧版本的其他依赖服务。

与单体系统相比,更难以对整个系统进行集成测试。

架构必须从一开始就深思熟虑:如果服务之间的凝聚力过大,也会失去大部分优势。

加大通信力度:在服务之间的通信方面,需要进行投入。服务的通信之间容易发生故障。

难以监控整个系统:大量组件对监控来说,是噩梦。

花时间学习:使用微服务需要学习,这需要时间。

复杂性:越来越多的微服务使整个系统更加复杂,难以监控。

“所有这些东西都散在周围。如果没有很好的工程流程,企业最终获得一大堆东西,然而根本不会使用。” – Shippable联合创始人兼CEO Avi Cavale说道。

“在基于微服务的平台上调试生产问题是完全不同的操作。如果没有相应的监测,记录和跟踪设施,系统的复杂性会显著增加。这就像迷宫一样。工程实践和标准化至关重要。” – SimilarWeb研发副总裁 Daniel Ben-Zvi 说道。

“记录到一个地方有挑战性。Loggly,Splunk或Heroku等第三方日志聚合服务是非常好的解决方案,但价格非常高。根据我的经验,遥测特别集中的日志是最大的难题。必须考虑每个服务的详细程度。否则,企业可能要花费50-60%的成本进行记录。”-来自微软公司SRE工程师 Sonu Kumar。 微服务面临的挑战和解决方案

当转向微服务时,如下这些是技术领导者和开发团队面临的最大挑战。 • 挑战1:一次切换所有系统 • 挑战2:拆分系统 • 挑战3:组织认同 • 挑战4:团队

> 挑战1:一次切换所有系统

“从单体架构切换到微服务架构不是一次就可以完成的。如果企业有单体服务器,那么其周围可能被存储库,部署任务,监控和其他许多事情包围。一起更改并不容易。” – AdRoll软件工程师Brujo Benavides说道。

“如果一个公司从未有任何微服务经验,即使是新建,也会比想象的更难。” – LogMeIn DevOps工程师 Viktor Tusa 说道。

white_check_mark:可能的解决方案

“那时候我们做的是保留单体服务器,但是任何新的服务都是通过微服务来开发的。”(Brujo Benavides)

挑战2:拆分系统

“如果组件和服务聚集在一起,隔离起来相当具有挑战性。(Robert Aistleitner)。需要定义各个部分之间的交互和流程。如果没有很好的定义,系统会产生更多问题。”- StyleSage高级开发人员 Jose Alvarez 表示。

“将系统拆分成微服务有许多不同的规则,没有特定的模式,没人会告诉你,如何在应用程序中使用它。而且,没有两个相同的微服务”。 – Recart 首席架构师大卫·帕普说道。

white_check_mark:可能的解决方案

“把单体系统分解成微服务的唯一方法,是首先检查单体系统,看看它最“痛”在哪里。将这些部分拿出来并转化成微服务“。 – Emarsys工程副总裁Andras Fincza表示。

监控所有部分是如何工作的以及他们在做什么。监控过程中,可以很容易地发现和解决问题。(Jose Alvarez)

模块by模块渐进地分离单片系统是最好的方法。想一次做所有事情,一定会失败的。

监控工具提示: • New Relic • Datadog • Influxdb • Grafana

挑战3:组织的支持

“获得组织认同可能是最难的部分。” – 来自 Steven McCord ,ICX Media创始人兼CTO。

这不是一个技术决定。需要清楚说明微服务架构的好处,从而说服企业重新分配资源。在企业接受变革之前,这是一个漫长而乏味的过程,组织规模越大,决策的时间越长。

white_check_mark:可能的解决方案

说服组织改用微服务的最佳方式,是将非核心部分转换为微服务。通过这种方式,来展示微服务的优势。

挑战4:团队

“团队本身面临着最大的挑战,它需要不同的思考。” “开发人员必须花费更多时间来了解什么是端到端场景。他们需要熟悉这些技术,需要转换思维方式。”

“对于一个在端到端测试的世界中工作的人来说,突然把它分解成小块,是不舒服的,这更多是文化上的变化。”-Shippable 联合创始人兼CEO Avi Cavale说道。

white_check_mark:可能的解决方案

从非常小的可以真正受益的方面开始,并选择应用程序的非关键部分。获得一个小团队的支持,并将这部分转换为微服务。一方面来证明微服务的优势,另一方面逐步向企业扩展(Avi Cavale)。

微服务落地要避开的坑

“避免同时将整个系统切换到微服务。” – Emarsys工程副总裁 Andras Fincza 说道。

“你能犯的最大的错误就是,没有创建一个微服务架构变化可能带来的影响概览。在实际开始实施新方法之前,必须包括大量移动组件。“ – Usersnap工程副总裁Robert Aistleitner说道。

“单体架构很容易改变内部接口。只需重构代码,然后运行测试。使用微服务,API必须可靠,你不一定知道你所有的客户。如果没有API的话,会给未来带来许多麻烦。此外,确保有分布式跟踪系统。”-来自 Daniel Ben-Zvi ,Similar Web研发副总裁。

“不要在没有搞清楚平台和依赖关系的情况下,尝试切换到微服务。此外,也要避免认为微服务都不错,因为每一个微服务可以用不同的语言来编写是一个不好的做法。” – 来自 Viktor Tusa ,LogMeIn DevOps工程师 。

“处理数据至关重要。搞砸数据非常容易,但是很难恢复。数据迁移需要更多步骤。” – Emarsys工程副总裁Andras Fincza表示。

“在微服务之间共享数据是一个很大的禁忌。如果两个服务操纵相同的数据,将遇到一致性问题,并消除所有权。“ – Daniel Ben-Zvi&Varun Villait二者共同认为。

“把应用程序分解成太多太小的东西,或者强迫把系统转变成微服务,这不应该是微服务 – 仅仅是炒作”。- 来自 Doctusoft首席开发Csaba Kassai 的观点。 来自技术领导型企业的微服务架构最佳实践

创建微服务之间的隔离,可以根据需要快速更改它们。这通常需要在几个层面进行隔离:

运行时流程:这是最明显的,也是普遍采用的过程。以前只有一个流程,而现在有很多。这里的主要成本是采用某种形式的分布式计算,这很难做到。会导致采用容器化,事件架构,各种http管理方法,服务网格和断路器。

团队/文化:分离团队,给予自主权,意味着划分人与人之间的沟通。这往往会导致知识孤岛和工作重叠(解决选择性与资源效率的选择)。

数据:采用像微服务这样的分布式计算最大的影响是它影响企业的数据。以某种形式对数据进行划分,需要在系统级别重新整合,以给出“一个系统”的印象。这在伸缩方面有潜在好处,但也需要相比简单的单一数据架构方法的更多想法。(来自David Dawson) 如何选择微服务当中的技术栈?

这是不同意见开始碰撞的地方…

一方面,人们认为使用什么技术和编程语言并不重要。

“几乎所有的问题都可以用任何技术解决。人们花费太多时间寻找正确的技术,如果以迭代的方式来做,你就有时间思考,并看到它的实际应用。错误的决策也可以得到缓解。” – Andras Fincza ,Emarsys 工程副总裁表示。

“大多数现代语言(Python,Java,C#,Node / JavaScript)同样快速且可扩展。从这个角度来看,语言无关紧要。每种语言都有其优点和缺点。大部分时间,语言选择是根据个人的喜好,而不是技术参数。” -Andras Fincza , LogMeIn DevOps 工程师说道。

花费大量的时间来选择最好的技术是不值得的,因为差异很小。

“选择技术的重要性被高估了。如果运行成本很重要,那么就可以接受,对我们来说没那么重要。” – Andras Fincza , Emarsys 工程副总裁。

“如果是新建项目,选择程序员最了解的语言。如果不是,选择客户端上最佳覆盖业务系统的语言。” -Viktor Tusa , LogMeIn DevOps 工程师 。

“微服务的好处在于它被封装在一个微服务中,只需要给外部的接口来谈论这件事。只要有一个界面就够了。“ -Steven McCord , ICX Media创始人兼CTO 。

选择合适的技术不仅仅是技术问题,也是一个决策。如果选择一种具有10种不同编程语言的微服务架构,要确保团队能够处理该问题。

“我不推荐混合太多的编程语言,因为招聘会变得更加困难。而且,程序员的上下文切换会减慢开发速度。“ – Robert Aistleitner , Usersnap工程副总裁。

“必须有意识地选择想要建立的开发团队类型。如果想使用许多不同的编程语言,需要建立一个能够使用和学习不同编程语言的动态团队。“ – Steven McCord , ICX Media创始人兼CTO 。 实用的技术建议 “我强烈建议在Google云端平台中使用管理服务,如App Engine。这将肩负很大的负担。此外,选择语言/技术时/框架时,选择合适的针对特定微服务的使用情况是重要的,不要因为熟悉它,而强迫选它。” – Csaba Kassai ,Doctusoft 首席开发。

以下来自Brujo Benavides:

一些技术领导者乐于推荐一些技术,这些技术可以很好地适用于服务特定角色的微服务。在选择微服务技术时,建议考虑: • 可维护性 • 容错 • 可扩展性 • 架构成本 • 易于部署 Brujo团队的一些微服务框架/技术示例: 
• Scrapy for web crawling • Celery + RabbitMQ用于微服务通信 • NLTK + Tensorflow(以及其他一些)用于机器学习部分 • AWS服务 如何选择合适的技术/语言?

在为微服务选择编程语言/技术时,需要考虑很多事情。

其中最重要的就是看你的开发人员具备哪些能力,以及语言/技术背后有多大的支持(工具,社区……)。根据我的经验,公司倾向于根据其开发人员的能力选择一种编程语言。“ – Csaba Kassai , Doctusoft首席开发人员。

“使用技术背后有很多支持(资源和活跃的社区)。我推荐Ruby和JavaScript,可以得到很多支持,如果出问题,很多人都可以提供帮助。只要确定有很多人使用它,选择语言不应该是问题。如果团队不具备这些知识,可以依靠外部资源。“ – Varun Villait,Industry CEO。

“另一个因素可能是图书馆可以用来加速项目的语言。你理想的语言的某些东西可能图书馆没有,不得不自己发明,这是另外的时间流失。容错和可扩展性也是重要因素。如果从现在开始的几个月内,你不得不重新编写一些东西,因为最初的选择无法扩展,那不如放弃。这一切都归结到一个特定的团队情况,他们愿意进行投入。” – Greg Neiheisel , Astronomer联合创始人兼 CTO 。

Emarsys就是这样看待这个过程的:

在Emarsys,如果他们想应用一种新的编程语言,开发人员需要提供真实的,合乎逻辑的理由,并咨询主要开发人员。团队聚集在一起讨论技术的优缺点。

他们总是用不同的技术创造一个尖峰解决方案。这可以让他们试验一个给定技术的边界,看看它是否可以应用于给定的微服务。这对于发现技术的局限性是完美的。

“建议使用您的团队已经熟悉的语言。这样,他们可以工作更舒适,进展较快。” –来自 Andras Fincza, Emarsys 公司工程副总裁 。

这是他们在SimilarWeb上所做的:

作为一家大数据和分析公司,我们面临着非常大的挑战,这增加了选择错误技术的风险和影响。单线程框架(如NodeJS)虽然适用于网络绑定服务,但在处理实时密集型数据处理时不会扩展。

工程师通过平衡战术和战略需求,同时考虑技术和组织的约束条件,来确定使用哪种技术。企业正处于快速成长阶段吗?服务是否需要处理大量数据?是否希望将新技术添加到堆栈中,是因为相信它的生态系统,还是使用我们已经掌握的现有技术?想要试验吗?能找到对此充满激情的工程师吗?是否愿意长期致力于这项技术?技术的生态系统是一个主要因素。我们希望与开源社区合作,使用和贡献现有的框架,而不是重新发明。

定义明确的指导方针甚至是清单可以帮助促进健康的决策过程,缩小可能的技术选择范围,从而选择最适合的团队和产品方案。

David Dawson提出的选择建议:

1.从数据架构的角度来看,需要一些可以轻松地将数据同步到服务之间的网络,并保持一致的可用状态。有很多种方法,这正是微服务部署中所需要的。可以观察实现这些模式的各种框架和技术。

2.一旦确定了模式和方法,就可以使用可用的资源来分析。如果已经决定采用大量反应式编程的数据流方法,并且拥有Java开发人员,那么选择Spring,Spring Cloud Data Flow和Kafka并且部署到某种形式的Cloud Foundry上(如果可以得到它!)。

如果需要大量更重的数据转换,请带上Spark或Kafka Streams 来解决这个问题。如果有JavaScript 开发人员,那么这个问题是没有道理的。相反,你会希望在JS运行时(clojurescript等)采用一些功能语言,再次使用一些类似的反应式集成技术(比如Kafka),并从那里采取。

关键要点: • 不要强调完美的技术,采取迭代的实验方法。 • 每个微服务架构都是独一无二的; 所选择的技术要与系统需求保持一致。 • 太多不同的技术使招聘更加复杂。 结论: 切换到微服务架构时,有很多挑战。在将系统转换为微服务之前,请确定要实现这一目的的真实原因。优点和缺点的分析会是一个很大的帮助。首先考虑系统的特性,而并非仅仅改变那些伤害最大的系统部分。不建议从头开始使用微服务架构,因为从一开始就明确界定微服务的边界是困难的。

如果决定切换到微服务,请采取渐进式方法,并从系统中取出非关键的一小部分,来了解它是如何工作的。这也是获得更多微服务的好办法。

对微服务来说,没有最好的方式可以选择完美的技术。每个与技术有关的决定都受到团队当前知识的影响,也受到公司未来招聘计划的影响。在某些情况下,选择微服务技术更多的是一个招聘决定,这取决于将来要建立一个什么样的开发团队。

为了缩窄可能的技术范围,来自Emarsys 的Andras Fincza,SimilarWeb的 Daniel BenZvi和David Dawson提供的经验值得借鉴。

文章来源: https://www.tuicool.com/articles/zaMnIz3

http://blog.shurenyun.com/10wei-ji-zhu-ling-xiu-gao-su-ni-tang-guo-de-wei-fu-wu-na-xie-keng-he-zui-jia-shi-jian/

实录分享|微服务落地践行渐进,4个Q&A一窥金融微服务现状

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。

PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。

PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。

DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。

数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。

DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。

敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。

例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。

微服务落地的必要条件

微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。

对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。

容器和微服务共生

容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。

不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。

基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。

变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。

首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:

1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。

数人云微服务On PaaS 产品体系

数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。

数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。

服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。

Q&A

Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下? 
A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。

在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。

但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q&A

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别? 
A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。

但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同? 
A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q&A

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系? 
A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。

轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。

把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。

如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。