写点什么

不同类型的微服务?

  • 2016-04-25
  • 本文字数:1792 字

    阅读完需:约 6 分钟

最近,有许多微服务领域的讨论,但是这些讨论大多都是关于如何从头开始构建微服务应用的,Mark Little 认为,微服务的初衷在于改造已有的应用,提高其敏捷性,他讨论了在这种场景下,实现微服务的最佳实践。

Mark Little 博士是 Red Hat 中间件部门的工程副总裁,他领导着 JBoss 的技术方向和研究 / 开发工作。在此之前,他曾经担任过 SOA 技术开发的主管,并负责标准的制订。

在 Mark Little 最新的一篇博客文章中,他回顾了自己从事微服务相关的一些经历和对微服务的认识,他依然愿意在这个领域不断思考,并与其团队成员进行交流,从而推动行业思想的发展。

在这个过程中,有些困扰他的问题变得逐渐清晰。长期以来,人们思考的可能是微服务与SOA、分布式系统以及DevOps 的关系,而且也有很多的项目和产品来帮助开发基于(微)服务的架构。但是,除Red Hat 以外,大多数关于微服务的文章都是从头开始构建的。这其实也反映了大多数开发工作的关注点:从头(Greenfield)开发,重新对系统进行架构,然后完全重建。

不过,微服务最初并不是这样的,如果读一下最初的文献的话,尤其是来自Netflix 的文章,就会发现微服务的理念(或者Adrian Cockcroft 最初所说的“Adrian Cockcroft”)是与已有系统息息相关的,它致力于将它们重构为组件(服务),这些组件能够独立地部署、版本化和发布。这里的理念在于为已有的系统(brownfield)构建微服务。Mark Little 虽然一开始就知道这些背景,但是一直以来他始终认为这种方式与从头开始构建所使用的过程、工具以及方式都是完全相同的。直到最近,他才意识到中间的差别。

有些团队会基于已有的系统进行改造,实现微服务,这是很有价值的。大多数人所面临的都是已有的应用,就像Netflix 那样,因此这种方式更具有实用性。它不需要我们好高骛远,每次只需进步一点点即可,这方面是作者以前所没有太多关注的。为了支持这些微服务,也需要对基础设施进行一些很重要的简化。

在一个样例中,他们所面临的是单体应用中的已有组件。因为团队是基于Java EE 的,所以具体的表现形式就是多个WAR(Web Archive)或JAR(Java Archive),这些文件会放到一个EAR(Enterprise Archive)中,但是这个例子本身与编程语言和框架是无关的。在这个例子中,目标是将单个组件拆分为微服务,这样当某个WAR 中的内容发生变化的时候就不需重新创建整个EAR 包了。

如果从完全重建的角度来看,这其实没有实质性的不同。不过,在分布式场景方面,我们可以采取一些变化,至少可以进行简化,这里不需要命名服务(或类似的机制)来定位各种各样的服务所在的位置,同时也不需要SLA。实际上,因为我们知道服务的API,并且这里的目标在于提升开发过程的敏捷性,所以,可以将API 硬编码到“客户端”中(应用的其他部分)。从事后来看,很多地方都是可以硬编码的。可以借助地址绑定或底层的网络,如REST/HTTP 使用URL 来表示服务的名称/ 地址,当然,这样的话需要DNS 实现绑定。

到目前为止,这是可行的,到一定程度之后,就会引入传统分布式系统的复杂性了,不过,我们还没到那一步。团队的关注点在于:“作为开发人员,我该从哪里开始拥抱微服务呢,在不开发、不安装过多基础设施的前提下,该如何取得成功呢?”。Mark Little 认为这种方式的简化/ 硬编码/ 依赖基础设施能够在一定程度上提供帮助。

当提到微服务时,我们经常读到的内容就是中心化的日志、事件驱动方式、协作(orchestration)以及部署技术,但是,当面临预先定义的组件/ 服务时,如果我们想借助微服务来提升敏捷性的话,这些技术其实并没有那么重要。借助硬编码以及一些自动化的方式,完全就能实现。

这是一种新型的微服务吗?事实上并非如此,这是一种不断演化的方式,其实与之前的CORBA 和Java EE 应用并无分别,我们会通过硬编码、接口的方式进行手动编码,随着分布式应用复杂性的不断增长,开发人员需要基础设施和工具的更多帮助。所以,这种方式毫无疑问也是微服务,因为它的目标依然是让团队更加灵活、具有独立的生命周期,只不过它更加聚焦于某一点,或者说更加实用。

在将已有的系统往微服务架构改造的过程中,Mark Little 所述的这些观点,应该会对我们提供一些借鉴和帮助。


感谢陈兴璐对本文的审校。

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

2016-04-25 19:002466

评论

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

墨芯人工智能加入龙蜥,携手打造软硬协同稀疏化计算平台

OpenAnolis小助手

人工智能 开源 龙蜥社区 CLA 墨芯

怎样将数据从Oracle迁移到TiDB

TiDB 社区干货传送门

Oracle 到 TiDB (OGG)

TiDB 社区干货传送门

2022 年 TiDB 社区年度总结,2023年,我们一起兔飞猛进

TiDB 社区干货传送门

稳定可靠、安全可信的云存储-华为云OBS对象存储

IT科技苏辞

支撑20亿+用户变美,看华为云OBS对象存储服务与美图的合作

IT科技苏辞

金航数码选择应用 TDengine 时序数据库,改造现有数据库架构

TDengine

数据库 tdengine 时序数据库

TiDB 同步数据到 Kafka 最佳实践

TiDB 社区干货传送门

神州数码正式加入CNCF云原生计算基金会,携手构建云原生技术生态

科技热闻

阿里IM技术分享(九):深度揭密RocketMQ在钉钉IM系统中的应用实践

JackJiang

RocketMQ 即时通讯 im开发 开源im 钉钉IM

华为云CDN下载加速,“火速”留住用户

科技说

不愧是阿里内部供应的Kafka笔记,深入浅出,全是干货

小小怪下士

Java kafka 程序员

TiDB 的“聚簇因子” -- 从 cop task 到 shard_row_id_bits

TiDB 社区干货传送门

性能测评 OLTP 场景实践

为什么我们要从MySQL迁移到TiDB?

TiDB 社区干货传送门

华为云OBS对象存储,一站式解决企业数据存储难题

科技怪授

YMatrix 番外篇|透过镜头,那些不为人知的故事

YMatrix 超融合数据库

车联网 超融合数据库 C++ YMatrix 研发故事

数益工联 x TiDB丨如何运用 HTAP 挖掘工业数据价值?

TiDB 社区干货传送门

记一次因 GC bug 导致 TiKV 存储占用不均的问题处理

TiDB 社区干货传送门

管理与运维 故障排查/诊断

海纳百川,华为云对象存储服务OBS给你无限可能

科技怪授

OBS

艺多不压身!华为云CDN成众多企业网络支撑

路过的憨憨

数据存储难?华为云对象存储服务OBS带你全方位解决

IT科技苏辞

“互联网+”的时代,华为云如何助力企业处理海量数据?

科技怪授

OBS

中科院自动化所历时9年打造的类脑认知智能引擎“智脉”正式开源部署至OpenI启智社区

OpenI启智社区

类脑计算 OpenI启智社区 智脉 开源开放 中科院自动化所

云上提速哪家强?华为云CDN加速成首选!

科技说

助力企业服务体验升级,华为云CDN这样做

路过的憨憨

面向对象分析与设计的底层逻辑

阿里技术

面向对象设计

拒绝等待,华为云CDN下载加速就是要快人一步

科技说

专属企业的加速“小帮手”——华为云CDN

科技说

自建还是第三方?华为云对象存储服务OBS 成为企业更优选

IT科技苏辞

年终有奖 | 三分钟,一起创造更好的 StarRocks!

StarRocks

企业号1月PK榜,火热开启!

InfoQ写作社区官方

热门活动

不同类型的微服务?_语言 & 开发_张卫滨_InfoQ精选文章