GMTC深圳站售票最后一周,点击查看最新日程>> 了解详情
写点什么

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

  • 2017 年 2 月 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 年 2 月 07 日 18:007764
用户头像

发布了 217 篇内容, 共 55.0 次阅读, 收获喜欢 70 次。

关注

评论

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

Redis源码剖析——客户端和服务器,springboot入门程序

Java 后端

RPC服务和HTTP服务对比,java基础实验报告总结

Java 程序员 后端

【Flutter 专题】13 图解最基础的 http 请求方式

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 11月日更

Spring Boot 实战(9) springboot 整合 JPA,2021必看

Java 程序员 后端

spring boot 整合Swagger2 构建API文档,linux学习路线图

Java 程序员 后端

Redis-中会涉及那么多数据结构,那你数据对象的底层实现方式你都了解吗?

Java 程序员 后端

Redis分布式锁的原理以及如何续期,java程序设计实验实训教程答案

Java 程序员 后端

Redis持久化--Redis宕机或者出现意外删库导致数据丢失--解决方案

Java 程序员 后端

Rpc与RMI服务,java面试笔试题代码

Java 程序员 后端

Spring Boot 实战(11)整合MyBatis-Plus,mysql原理相关文章

Java 程序员 后端

Redis、MongoDB及Memcached的区别,老男孩linux运维54期视频

Java 程序员 后端

RPC框架编写实践——服务治理的基石,这位阿里P7大牛分析总结的属实到位

Java 程序员 后端

Seata 新特性,APM 支持 SkyWalking,java流式编程原理

Java 程序员 后端

Shiro等权限管理框架本质很简单,一个注解+拦截器就可实现

Java 程序员 后端

Spring Boot Redis 实现分布式锁,真香,kalilinux入侵教程

Java 程序员 后端

RocketMQ ACL版本升级过程中的曲折经历(大厂线上环境大规模MQ升级开启ACL实战)

Java 程序员 后端

Spring Boot 2(1),蛙课网java教程资源库

Java 程序员 后端

Redis-数据库、键过期的实现,跟面试官侃半小时MySQL事务隔离性

Java 程序员 后端

Redis常用命令总结,java项目实例教程详细

Java 程序员 后端

Redis应用之缓存实现,java异步编程实战pdf

Java 程序员 后端

linux 环境安装Flutter

坚果前端

flutter 安装 11月日更

spring boot 使用Spring Cache集成Redis,java编程基础实验报告小结

Java 程序员 后端

redis数据迁移之redis-shake,java高级技术经理面试题

Java 程序员 后端

Sentinel:万字详解微服务的哨兵机制,我跪了,mysql编程入门教程

Java 程序员 后端

Servlet+JSP(七,java界面开发的三层架构技术

Java 程序员 后端

shiro(三)shiro实战,java面试题项目中的难点

Java 程序员 后端

Spring AOP 源码分析——创建代理对象,绝对干货

Java 程序员 后端

Redis的各种用途以及使用场景,mybatis技术原理

Java 程序员 后端

Sentienl 动态数据源架构设计理念与改造实践,阿里P8大牛手把手教你

Java 程序员 后端

002|CocoaPods 优化知多少?

棒棒彬👻

CocoaPods 认知偏差 工程能力 开源软件

Spring Boot 谷粒学院、谷粒商城项目问题汇总,tomcat面试题

Java 程序员 后端

数据cool谈(第2期)寻找下一代企业级数据库

数据cool谈(第2期)寻找下一代企业级数据库

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