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

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

关注

评论

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

如何选择合适的云桌面系统方案?

上海锐起科技

文化产业怎么定义?需要用到堡垒机吗?

行云管家

文化 堡垒机 文化产业

Linux安装nginx

六哥是全栈

Linux NGINX 安装

数据工程(三):数据桥梁的基石——深度剖析数据集成与整合中的采集艺术

数造万象

数据治理 数据采集 数据集成 数据孤岛 数据工程

QCN9074: The Future of High-Performance Wireless Solutions

wallyslilly

QCN9074 QCN9024

仓储管理这些坑,你有没有经历过?

天津汇柏科技有限公司

低代码 AI 人工智能

“京东云深海数据平台” 焕新升级 免费体验!

京东科技开发者

一文读懂PINGPONG:0成本在普通家用机上运行多个网络节点

西柚子

Databend Meta-Service 架构概述

Databend

得物App白屏优化系列|归因篇

得物技术

android 稳定性 企业号2024年8月PK榜

十五年以来 — 战略性云平台服务的演进路径之全面呈现(含亚马逊、微软和谷歌)

Moehoo猛虎

微软 AWS 云服务 Gartner 魔力象限

火山引擎携手居然之家,共推家居行业的数智化发展

新消费日报

讯飞星火版「Her」正式上线!成立仅16月的无问芯穹完成近5亿元A轮融资|AI日报

可信AI进展

链动2+1系统模式开发搭建

V\TG【ch3nguang】

大模型在研发数据中台的应用实践

百度Geek说

大模型 研发、 数据库· 产品架构

积硅步以致千里,积怠惰以致深渊

Anliven

成长 激励

未完待续

Anliven

职业发展 价值

活动火热报名中|搜索进化论:基于大模型的企业级AI搜索

阿里云大数据AI技术

人工智能 AI搜索 搜索开发工作台

地理围栏,打造智能生活新边界

HarmonyOS SDK

HarmonyOS

缓存预热有哪些方案?

江南一点雨

淘宝商品评论API:深入探索商品使用场景与评价信息

代码忍者

人工智能 | Mistral 大语言模型

测试人

人工智能 软件测试

有效阅读

Anliven

方法 个人提升 阅读

天翼云HBlock:Step by step,一杯咖啡的时间轻松搭建企业存储集群

三掌柜

天翼云HBlock

智源研究院举办第二期“数据与行业应用Workshop”

智源研究院

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