“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

实现云原生应用,先理解架构微服务化

  • 2016-07-17
  • 本文字数:3744 字

    阅读完需:约 12 分钟

Cloud Native 直译过来是云原生,是面向云环境而设计的软件架构。腾讯云布道师刘永峰认为云原生并不是新的技术,它是基于微服务架构思想、以容器技术为载体,一种产品研发运营的全新模式。InfoQ 围绕微服务如何实现云原生应用为主题对刘永峰进行了采访。

受访嘉宾介绍

刘永峰,腾讯云高级产品经理,布道师,十余年的产品及研发管理经验。国内最早一批从事可信计算研究的探索者。曾就职于中兴通讯,负责流媒体 Server 后台架构设计,Linux 内核相关的研究。2011 年起加入腾讯,一直从事公有云的产品设计,云计算市场趋势分析和研究,云计算技术的推广与普及。在技术和产品领域均具有丰富的行业经验。目前主要关注 Docker,微服务,Cloud Native, 企业云化趋势等相关领域。

InfoQ:能否根据您的理解给微服务下个定义?微服务需要“微”到什么程度?

刘永峰:微服务,按照比较学术化一点的解释是一种面向服务的,有特定边界的松散耦合的架构。我个人观点,可以从以下三个关键点去理解微服务:一、每一个微服务是一个独立的自治系统,不依赖外部组件能够独立运行。二、对外只能通过 API提供服务或者获取服务。三、粒度足够小

到底微服务多大才合适,是一个经典的问题。我认为这个没有固定的答案,而是根据自己的业务特点,团队组织方式决定的。康威定律提到,有什么样的团队组织方式,就有什么样的业务架构。所以,首先,微服务的粒度和团队组织方式是相关的。其次,粒度大小,与业务功能的构成相关。一个微服务,在划分上,尽量做到一个模块中的业务高度类聚集,和外部模块能够做到松耦合,这样会有更多的灵活性。最后,微服务的粒度,还和数据有关系,一个微服务,尽量不要做到和外部频繁的交互数据,因为大量的 API 交互对性能和可靠性都会有影响。

InfoQ:相比 SOA 而言,微服务的重大优势是什么呢?微服务普遍适用于各种需求各种架构吗?微服务是未来吗?

刘永峰:微服务,是一种去中心化的架构。微服务一般和更细粒度的容器去配合使用,并且和云天生有很强的共生性(又称云原生:Cloud Native)。从架构的发展来看,其实一直是朝着去中心化的趋势发展的,从早期的集中式架构,到分布式架构,再到现在更细化的微服务。去中心化的架构,具备更强的灵活性以及鲁棒性,并且更适合云的特点。

微服务化比较适合无状态,对延时要求不高的业务场景。电商类的应用可以将业务打散,拆分成各个服务,服务之间可以通过 API 进行交互。但是,对延时敏感,或者数据无法拆分的场景(譬如大数据处理、视频直播、一些游戏类)而言,微服务是无法发挥其特色优势的。

微服务可能是未来一种非常主要的,应用广泛的架构,但是并不一定说它会统治一切。微服务是具备自己的一些应用场景的。

InfoQ:您认为微服务化改造中最大的难点是什么?

刘永峰:微服务在实践过程中,最大的问题是团队之间的运作和管理的问题。刚才我们提到过康威定律,业务架构,总是和团队组织架构想匹配的,当你把一个大的系统,拆分成小的服务时,团队会随之变化。

团队组织调整之后,就需要解决团队的人员管理问题,需要让团队的成员适应微服务的开发模式。因为微服务,对每个程序员的要求是比较高的:每个程序员的权责会更明显,需要标准化接口、书写规范文档,而且一般需要有 DevOps 的工作。

微服务化的改造,难点不在于没法拆分,难点在于很多的人的思想在于停留在以前的架构思想下。突然间大量的改造,公司人员会有非常大的不适应性。我的建议是,逐步改造、持续迭代地改造架构。新的业务、新的团队可以独立地采用微服务化的方式去运作。这里我举个典型的例子,某个企业进行了架构微服务化改造之后,每个团队会负责两三个关联性比较强的服务,但是团队往往会倾向于把这两三个微服务合在一起。这种情况下组织架构与业务架构不匹配,所以业务架构必然会朝着更匹配组织架构的方向去发展,这就是康威定律在起作用。

InfoQ:怎么处理微服务与外部相连,并获取数据的问题?

刘永峰:我的理解,在设计时就需要考虑到微服务有哪些数据需求(见问题一的第二小问):微服务都是通过 API 对外提供服务,本身是一个独立的自治系统,所以不存在需要与很多数据中心相互连接的情况;如果需要通讯,直接适用公网连接就可以了。

换句话说,微服务和微服务之间的数据通讯是通过 API 调用的。没有所谓的内部的进程间、共享信号、共享内存队列的模式。一个微服务对外提供的服务一定是封装好的、接口式的。

InfoQ:如何看待微服务、容器技术的两者的关系?两者结合会带来什么样的新趋势?

刘永峰: 目前去中心化的思想越来越广泛,微服务与容器就是很好地践行了这种思想。微服务是一种架构思想,而容器、或者说以 Docker 为代表的容器技术,是一种运行的载体。容器天生适合细粒度的微服务,容器的管理和分发需要 Docker 的支持。两者结合,再结合团队组织的一些思想,其实就是云原生 Cloud Native 所倡导的东西。

为什么会出现这种趋势,这和目前创业公司的产品研发模式是相匹配的。随着互联网与云计算的发展,什么样一种架构或者产品研发模式是适合云的模式的?是传统的集中式架构吗?分布式架构吗?我们可以看看现在创业公司的一些特点:完全基于云端,轻资产,小团队作战,快速的产品迭代。要适应这些特点,就必须基于云的原生特点去设计应用架构,所以微服务和 Docker 的发展的新趋势就是去实践 Cloud Native。

但是并不是说所有的构架都要顺应这样的变化趋势。对于传统的 IT 公司,一个部门数百人做一个项目,每个小团队负责一个小模块,最后将各个模块整合在一起成为一个新的项目或系统。新版本的发布周期是半年或者一年,那这样的模式下,集中式架构可能就更适合他们一些。因此,架构还是要和公司的组织架构相契合的。

InfoQ:您刚才说微服务和容器结合会发展出 Cloud Native 的趋势,可否解释下 Cloud Native?

刘永峰: 到了云时代,全部应用基于云去构建。这时再套用传统的研发模式也是可以得,但是并不是那么的匹配 。Cloud Native 是指云原生的应用架构,是专门针对云的架构。它主要包括三个部分,一种全新的架构思想(微服务),一种业务运行管理模式,以及一种团队组织管理方式。关乎 DevOps、小团队、敏捷开发。Cloud Native 既不是一个新的技术,也不是一套新的架构,而是产品研发、运营的全新模式。它是在云的生态场景生长出来的,和云的关系是一种鱼和水的关系。

当然,Cloud Natve 也总是不停的在发展过程中,有可能未来还会融入到一些更新的东西来。

InfoQ:能否选出三个对云应用开发最具重要意义功能呢?

刘永峰: 我这里给出我自己对云服务三个觉得最有意义的功能:负载均衡、API、 快照

负载均衡:这是对容灾扩展非常重要的基础功能。正常工作时根据策略分发;出现问题时进行容灾;需要扩展时,在运营中动态地横向扩展。负载均衡开源技术比较多,理论上是可以自己去实现的;但是具体搭建实现比较困难,怎样确保性能稳定性。一般建议还是使用云服务商自带。

API:云的未来发展,应该想我们用电一样,有插座就可以用电。有了 API,就可以即时获取云;企业不需要去动手操作调用,不需要去理解 API 背后的细节。比如腾讯云现在提供的人脸识别服务,使用者通过 API 就可以使用了,不要你自己去具体实现人脸识别。

快照:某个时刻可以拍照留存,在出现问题的时候,可以恢复。

InfoQ:您提到容器天生适合细粒度的微服务,那么可以谈一谈 Docker 都有哪些场景化应用吗?

刘永峰: 我认为有以下五类应用情景:

  • 传统软件 SaaS 化: 单一总线型 -> 多租户(软件的设计要求很高) ; 克隆 【容器化之后就很容易去改造】,微服务 +Docker。可以在线上生成架构,不需要去服务器上配合。Docker 的粒度很细,节省资源
  • 企业私有的 PaaS 平台: 减少人力成本,提升效率;不需要底层的运维。
  • 企业级的 AppStore: 通过容器开发、分发应用。
  • 间歇式执行任务: 临时开启容器,用后再销毁。腾讯的大数据就是通过这个来实现。同时,也可以用它来自动化切换不同的场景,腾讯云的客户微影时代,白天跑业务,晚上跑大数据。
  • 构建微服务: 这点我们在上面有提到。

InfoQ:腾讯云对 Docker 的支持会是怎样的?

刘永峰: 作为公有云厂商,我们需要提供 Docker 的基础设施。 Docker 好比集装箱,我们云厂商提供港口仓库,企业创业公司用户可以运送集装箱过来。目前看,我们是不会把 Docker 相关所有的东西都做的,即便都做了也是没有竞争力的。

具体而言,我们考虑可以提供一个镜像的仓库,比如 Docker Register 这种,让用户更方便地下载存放镜像,让不同的操作系统版本更好地去支持各个版本的 Docker 镜像。此外,我们在研发一个虚拟机能够支持多个外网的 IP,解决一个外网地址映射多个单口的问题。

总而言之,我们会去做基础设施,好比做港口的高速公路、集装箱的堆场。有的云厂商在做 Docker 的编排,腾讯云现在还没有做这个;我们现在是去做基础设施,去协同定制更多的标准。

InfoQ 主办的 CNUTCon 全球容器技术大会即将开幕,特设微服务专题并邀请阿里巴巴、Netflix、中青易游、百度资深专家进行案例分享。不谈概念,只讲实践;希望能和参会者分享微服务架构应该如何落地。


感谢徐川对本文的审校。

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

2016-07-17 19:006421
用户头像

发布了 58 篇内容, 共 42.4 次阅读, 收获喜欢 35 次。

关注

评论

发布
暂无评论
发现更多内容

IPQ5018 IPQ6010 IPQ8072 Support Wallystech Latest Opensource Code Repository

wallyslilly

IPQ6010 IPQ8072 ipq5018

制作红木家具3d模型

3D建模设计

3D模型 材质贴图 纹理贴图 材质纹理

中企全球化:王文京与新加坡建筑企业集永成共谋数智化新发展

用友BIP

青椒云云桌面—低配电脑秒变高性能设计神器

青椒云云电脑

桌面云 云桌面 云桌面系统

5 种主要的云电脑解决方案 - 不同之处

青椒云云电脑

云桌面 云电脑 云桌面解决方案

用友承建!居然之家人力资源数智化项目成功上线!

用友BIP

少写代码,用更便捷的方式开发程序

代码生成器研究

如何降低代码的复杂度?

代码生成器研究

云桌面是什么?好用的云桌面推荐?

青椒云云电脑

云桌面 云桌面解决方案

手把手教你使用 RisingWave 流数据库

吴英骏

分布式 rust 流处理 物化视图 数据库设计流程

「X」Embedding in NLP|Token 和 N-Gram、Bag-of-Words 模型释义

Zilliz

nlp NLP 大模型 Milvus AIGC

云计算与低代码:加速应用开发与创新的双核引擎

快乐非自愿限量之名

云计算 云原生 低代码

软件测试/人工智能|Python Pip 常用命令大全

霍格沃兹测试开发学社

软件测试/人工智能|Python运算符:初学者指南

霍格沃兹测试开发学社

王文京与厦航董事长、党委书记赵东交流座谈,共商助力智慧民航建设

用友BIP

为什么说编程是新时代必学的技能?

代码生成器研究

前端又出新轮子Nue.js,但还是低代码更香!

伤感汤姆布利柏

前端 低代码 前端框架 极简主义 nue

如何降低代码的复杂度?

代码生成器研究

Java多线程系列4:线程协同

BigBang!

Java多线程

债务管理一体化领先实践,全面提升融资管理效率,有效防控风险

用友BIP

走软件开发的捷径——低代码之路

树上有只程序猿

软件开发 低代码 JNPF

微信小程序 WXSS 是如何编译的?

FN0

小程序 小程序容器

软件测试/人工智能|Python算术运算符:入门指南

霍格沃兹测试开发学社

还记得当初自己为什么选择计算机?

代码生成器研究

低代码开发平台有什么优势?

代码生成器研究

云桌面系统如何使用?云桌面的优势有哪些?

青椒云云电脑

云桌面 云桌面解决方案 云桌面系统

低代码开发平台有什么优势?

代码生成器研究

供应商企业在线询价招投标管理系统

金陵老街

如何为 3D 模型制作纹理的最佳方法

3D建模设计

材质 纹理 贴图 3D模型纹理贴图

每日一题:LeetCode-322. 零钱兑换

半亩房顶

面试 算法 LeetCode 动态规划 贪心算法

精选21款免费项目管理系统,哪款更适合你?

PingCode

项目管理 项目经理 项目管理软件

实现云原生应用,先理解架构微服务化_架构_木环_InfoQ精选文章