写点什么

与 Susan Fowler 探讨生产就绪微服务之问答

  • 2017-02-07
  • 本文字数:1848 字

    阅读完需:约 6 分钟

Microservices.com Practitioners 峰会是为从业者量身定制的微服务会议,峰会专注于介绍大规模采用微服务的实际应用。峰会将会于 2017 年 1 月 31 日在旧金山举行。演讲者包括来自 Uber、New Relic、Lyft、PayPal 和 Google 的微服务从业者。

Susan Fowler 是 Stripe 的工程师,她是《生产就绪微服务》一书的作者,并受邀会在峰会上发言。在 Uber 的时候,Fowler 致力于标准化微服务,并将微服务嵌入各种关键业务团队,帮助他们的服务变得更加可靠。

在峰会之前,InfoQ 采访了 Fowler,和她讨论了成功实施微服务架构的技术、业务和文化挑战。

InfoQ:可以在哪里看到微服务架构的理念和大多数组织的实际系统相关联,甚至是产生冲突?

Susan Fowler:在相关联方面,我认为采用微服务架构是很多软件应用程序发展的自然步骤。Monorepos(monoliths)很难大规模使用,许多工程组织可以发现,并确实发现现在规模化发展受到了限制(没有并发性,没有分区等等)。他们还发现,开发速度停滞不前,因为一旦应用程序很庞大且有很多工程师同时工作于相同的应用程序上时,在 monorepo 上部署开发就变得不太可能(从组织的角度来看)。一旦真的发生这种情况,最简单、最容易规模化的方法就是采用微服务架构。

这也正是大多数冲突发生的地方。由于采用微服务往往是软件系统发展的“下一步”,所以大多数系统的设计中都没有考虑到微服务架构,这会产生很多问题,其中一些是组织性的,另一些是技术性的。

比如说,从组织的角度上看,最终会有很多孤立的、没有关联的团队,除非你事先计划了很多跨团队协作,否则他们闷头做自己的微服务工作,但不知道系统的其他部分工作。最终微服务开发团队之间还会缺乏相互信任,他们不确定自己的服务所依赖的其他微服务是否是可靠的、稳定的、规模化的等等。

你也可能发现(与许多公司做的一样),很难在微服务生态系统中雇佣并运营单独的运营组织,开发人员需要学习接管他们微服务的运营职责(很多人可能会不习惯,或没受过培训,或准备开始做)。

在技术方面,比如说你可能会碰到很多奇怪的微服务,这些微服务没有什么意义,相互之间没有很好联系。这是因为它们之间的边界和它们的功能从没有在原来的 monolith 中恰当地定义过。

我经常能看到的另一个技术挑战是,微服务的基础设施需要非常复杂的微服务架构才能成功,许多习惯于运行 monolithic 应用程序的公司通常没有考虑到这些方面。

InfoQ:对于拥有传统 monolithic 系统工作经验的开发人员,他们想要转到写微服务需要学习的最重要技能是什么?

Fowler:当他们的组织开始采用微服务架构时,开发人员需要学习的最重要技能是他们最需要的操作技能。Monolithic 应用程序中,分离应用程序的开发和应用程序的维护相对容易,并且能在两个单独的团队之间拆分开发人员和运营人员的职责。在微服务架构中,情况并非如此,通常会有几十个、几百个或几千个微服务,因此对于微服务开发团队来说,分别雇佣开发人员和运营工程师是没有用的。此外,微服务架构允许开发者快速变动,因此从技术角度考虑也不需要有专门的运营工程师运行服务,开发者是最了解服务的工程师,他们能最好地运行它。

InfoQ:除了开发人员需要掌握的新技能,还要什么文化或组织的改变来支持微服务?

Fowler:真是很好的问题,要回答这个问题需要牵涉到很多内容(我写的书《生产就绪微服务》都是在回答这个问题!)我认为工程组织最要做的事情就是建立非常稳定的、可靠的、先进的应用程序平台基础设施(在微服务架构四层模型的第三层)。

InfoQ:正如你的博文《四层微服务架构》中所述的一样,成功的 MSA 需要成熟的基础设施层次。虽然单个微服务并不很有用,但每个系统都要从无到有。那组织如何管理好从遗留系统转换到微服务所需的开销?

Fowler:我认为大多数小公司不一定能从微服务架构中获益,而且我不认为大多数公司应该打破他们的遗留系统而转换到微服务。

在有些情况下,微服务真的非常非常好。首先,如果应用程序或是系统有点复杂,但是它的各种功能之间可以划分出非常清晰的边界,那么转为微服务并不会很痛苦(前提是,如你所述,所需的基础设施能够到位)。我觉得这是比较罕见的情况。

第二种情况是大多数工程师和公司经历的微服务故事:应用程序已经不能再扩展了,可扩展性的限制造成了严重的性能和稳定性问题,不能再对应用程序做些什么了,开发速度停滞不前。在这种奇特的常见场景中,调整微服务所需的额外基础设施工作非常容易:无论是构建基础设施,还是未来应用程序无法规模化。

查看英文原文 Q&A with Susan Fowler on Production-Ready Microservices

2017-02-07 18:0010443
用户头像

发布了 218 篇内容, 共 76.4 次阅读, 收获喜欢 76 次。

关注

评论

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

iofod - 新拟物设计的跨平台实践

iofod jude

最长字符串链,什么是“词链”?

掘金安东尼

算法 前端 8月月更

详解GaussDB(DWS) 资源监控

华为云开发者联盟

数据库 后端

有人相爱,有人年少财务自由,有人数据结构都背不出来

浅羽技术

Java 数据结构 队列 红黑树 8月月更

SpringBoot 打包发布

jar Linux SpringBoot 2 8月月更

优秀的程序员不能只懂技术

LigaAI

程序人生 敏捷开发 自我提升 职场发展 企业号九月金秋榜

活动报名:Tapdata 开源教程之异构数据库模型推演

tapdata

Tapdata 开源社区

设备健康管理“悬丝诊脉”之能源行业浆液循环泵

PreMaint

设备健康管理 设备预测性维护 设备状态监测

Spring Data 测试时的 Repository 提示为空对象

HoneyMoose

[极致用户体验] 如何实现响应式canvas?保持canvas比例?教你让canvas自适应屏幕宽度!

HullQin

CSS JavaScript html 前端 8月月更

视频结构化——原子能力解析

夏夜许游

物体检测 车牌识别 视频结构化 人体检测

再深一点:如何给女朋友解释什么是微服务?

浅羽技术

微服务 微服务架构 单体架构 微服务框架 8月月更

深势科技创始人&首席科学家张林峰:AI+分子模拟,赋能药物发现新源头

阿里云弹性计算

AI gpu 药物研究 分子模拟

渗透攻防Web篇-深入浅出SQL注入

京东科技开发者

sql 安全 mybatis Web H5

软件,英特尔人工智能的未来重点布局

科技之家

转转客户端持续交付—鲁班的构建管理

转转技术团队

CI/CD

nft交易平台开发流程

开源直播系统源码

NFT 数字藏品 数字藏品系统

🔛报名启动!「数智创新行」系列城市站沙龙首站开启

云桌派

阿里云视觉智能开放平台产品上新——能力前瞻

夏夜许游

人工智能 阿里云 元宇宙 图像分割 阿里云视觉智能开放平台

@DataJpaTest 进行测试的坑

HoneyMoose

FFmpeg打开输入文件

mei2022

8月月更

HMS Core Discovery第17期回顾|音随我动,秒变音色造型师

HarmonyOS SDK

音频技术

流程挖掘的价值:头部制造业千万级增长的底牌

望繁信科技

Docker下Prometheus和Grafana三部曲之三:自定义监控项开发和配置

程序员欣宸

Grafana Prometheus 8月月更

超简单!Redis中的持久化策略汇总

知识浅谈

8月月更

项目经理的职能在Scrum框架下没有完全消失

ShineScrum

Scrum 敏捷 项目经理

阿里云计算巢软件免费试用中心正式上线,企业用户可免费试用1个月

阿里云弹性计算

计算巢

了解“预训练-微调”,看这一篇就够了

博文视点Broadview

企业数据现状分析:为什么需要实时数据?如何高效挖掘实时数据价值?

tapdata

Tapdata

微服务面试必问的Dubbo,这么详细还怕自己找不到工作?

浅羽技术

微服务 dubbo 微服务框架 Dubbo服务 8月月更

云原生(二十六) | Kubernetes篇之Kubernetes(k8s)持久化

Lansonli

云原生 k8s 8月月更

与Susan Fowler探讨生产就绪微服务之问答_SOA_Thomas Betts_InfoQ精选文章