QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

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

  • 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:006688
用户头像

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

关注

评论

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

Linux之ab命令

入门小站

Linux

代码安全 | 什么是OWASP?OWASP十大漏洞解析

龙智—DevSecOps解决方案

漏洞 安全漏洞 漏洞防护 OWASP十大漏洞 静态代码安全

全球案例 | Hubspot 通过 Confluence 打造透明的协作文化,使之成为让无数人骄傲的企业

龙智—DevSecOps解决方案

Jira Atlassian Atlassian Confluence 协同办公软件 协同软件

踏雪痕项目管理学习笔记

踏雪痕

项目管理 PMP Certification 3月程序媛福利 3月月更

阿里云 OSS对象存储攻防

火线安全

云安全 阿里云;

用户文章 | 没有什么比现成的解决方案更香的了 - P4Python 玩家速看

龙智—DevSecOps解决方案

perforce P4 Perforce Helix Core P4Python

【网络安全】记一次网站站点渗透

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

自从用了这个APP,我的身体状况....

IT蜗壳-Tango

极客时间 IT蜗壳

在线JSON转CSV格式文件工具

入门小站

工具

2022年最新iOS面试题(附答案)

iOSer

ios iOS面试 ios开发 iOS 知识体系 iOS涨薪

郑州等保测评公司有哪些?在哪里?

行云管家

网络安全 等保 等保测评 等保2.0 郑州

Nebula Graph 在企查查的应用

NebulaGraph

数据库 开源 图数据库 知识图谱

一眼定位问题,函数计算发布日志关键词秒检索功能

阿里巴巴云原生

315权益日解读:“幸运”大牌和巨头,“挡枪”作坊和“小弟”?

易观分析

315晚会 央视315晚会 消费者权益

虚位以待 | 龙智有你更出彩

龙智—DevSecOps解决方案

求职 招聘

python pandas loc布尔索引(指定条件下的索引),你花了多久弄明白架构设计

程序媛可鸥

Python 程序员 面试

python 列表 remove()函数使用详解,最新手淘Python高级面试题及答案

程序媛可鸥

Python 程序员 面试

在线SQL(Insert/Update)语句转JSON工具

入门小站

工具

网站被DDOS攻击了怎么办?

源字节1号

开源 前端开发 后端开发

档案管理系统平台:助力实现档案管理现代化

小炮

python Excel数据表格转为HTML网页数据表格,阿里快手拼多多等7家大厂Python面试真题

程序媛可鸥

Python 程序员 面试

【模块五】设计微博系统中”微博评论“的高性能高可用计算架构

yhjhero

架构 #架构训练营

python sorted()函数及sort()方法,零基础Python开发

程序媛可鸥

Python 程序员 面试

中文在线研讨会 | 如何突破Jenkins瓶颈,实现集中管理、灵活高效的CI/CD

龙智—DevSecOps解决方案

ci 持续集成 持续交付

数据分析师如何正确地提意见?

博文视点Broadview

案例研究:亚马逊广告使用 PyTorch 和 Amazon Inferentia 扩展广告处理模型

亚马逊云科技 (Amazon Web Services)

模型 PyTorch

什么牌子的云堡垒机好用?效果好?

行云管家

云计算 堡垒机 云堡垒机

龙智荣誉 | 一封来自客户的感谢信

龙智—DevSecOps解决方案

感谢信

企业CICD规模化落地浅析

阿里云云效

云计算 阿里云 云原生 CI/CD 持续交付

攻击面管理(ASM)技术详解和实现

风向标

网络安全 asm 安全419 零零信安

Python 下载的9种方法,Python开发技巧

程序媛可鸥

Python 程序员 面试

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