你想学习微服务吗?目录

2025-06-07

那么你想学习微服务吗?

目录

做好准备,接下来是一大堆文字。微服务架构是一个永无止境的故事。我花了几年时间收集了这么多关于微服务的资源。现在将这些学习资源分享给你。你也可以在这里找到:https://kgoralski.gitbook.io/wiki/microservices

我接触这类架构越多,就越觉得它们更注重人,而非技术。实际上,“微服务解决了组织问题,却带来了技术问题”。它们当然不是免费的午餐

我在大型组织中看到的不是局部现象,而是人与人之间互动的模式,因此也是系统之间互动的模式。人际沟通的边界就是系统边界

所有荣誉均归于参考文献中的作者。

目录

定义

Adrian Cockcroft (Amazon) 撰写的“由具有有界上下文的松散耦合元素组成的面向服务的架构”

康威定律指出,设计系统的组织必然会复制这些组织的沟通结构[...] 组织结构图最初反映的是第一个系统设计,而这几乎肯定不是正确的[...] 随着学习的深入,人们会改变设计[...]。管理结构也需要随着系统的变化而改变...]

必读:

单体架构 vs 微服务架构

基于https://www.slideshare.net/aahoogendoorn/designing-and-building-a-microservices-architecture-stairway-to-heaven-or-a-highway-to-hell

整体式优势

  • 单一(分层)架构
  • 单一技术栈
  • 由多个团队维护的单一代码库

捍卫巨石https://docs.google.com/spreadsheets/d/1vjnjAII_8TZBv2XhFHra7kEQzQpOHSZpFIWDjynYYf0/edit#gid=0

整体式架构的缺点

  • 所有部分都是相互关联的
  • 许多其他系统连接到您的系统
  • 难以改变,难以维持
  • 发布间隔较长,从而增加了风险
  • 创新缓慢
  • 难以转向新技术
  • 扩展性不太好

微服务承诺

作者:“设计和构建微服务架构。通往天堂的阶梯还是通往地狱的高速公路?” - Sander Hoogendoorn

  • 产品不是项目这里
  • 可扩展
  • 去中心化治理
  • 可更换部件
  • 高性能(始终?)
  • 技术独立
  • 多语言持久化
  • 易于构建
  • 易于测试(是吗?)
  • 比单体应用更容易部署 产品 账户 订单 客户

微服务。但是……

  • 微服务到底是什么?
  • 微服务有多小?https://youtu.be/YQp85GzoxqA?t =2m48s
  • 微服务世界中的要求
  • 组件或服务
  • 谁拥有微服务?
  • 您使用什么技术?
  • 您应用什么协议?
  • 如何定义消息
  • 如何测试微服务
  • 业务服务跨组件运行时如何协调?
  • 如何构建部署管道?

参考:

打破整体架构

可以帮助你做到这一点的模式(查看下一部分):API 网关、前端后端、Strangler、反腐败层、Sidecar、Ambassador

模式

微服务模式

分布式计算的谬误

分布式计算的谬论是 Sun Microsystems 的 L Peter Deutsch 和其他人的一组断言,描述了刚接触分布式应用程序的程序员不可避免地会做出的错误假设。

谬误

基本上每个人在首次构建分布式应用程序时,都会做出以下八个假设。从长远来看,这些假设都被证明是错误的,并且会带来巨大的麻烦和痛苦的学习经历。——Peter Deutsch

  1. 网络可靠。
  2. 延迟为零。
  3. 带宽是无限的。
  4. 网络是安全的。
  5. 拓扑结构没有改变。
  6. 有一名管理员。
  7. 运输成本为零。
  8. 网络是同质的。因此,如果忽略了其中一个方面,设计就会很糟糕。

谬误的影响

  • 软件应用程序在编写时几乎没有针对网络错误的处理机制。在网络中断期间,此类应用程序可能会停滞或无限期地等待应答数据包,从而永久消耗内存或其他资源。当故障网络恢复正常时,这些应用程序也可能无法重试任何停滞的操作,或者需要(手动)重启。
  • 由于忽视网络延迟及其可能导致的数据包丢失,导致应用程序和传输层开发人员允许无限制的流量,从而大大增加丢包率并浪费带宽。
  • 流量发送方对带宽限制的忽视可能会导致瓶颈。
  • 对网络安全的自满会导致恶意用户和不断适应安全措施的程序的欺骗。
  • 网络拓扑的变化会对带宽和延迟问题产生影响,因此可能会出现类似的问题。
  • 多个管理员,就像竞争对手公司的子网一样,可能会制定相互冲突的政策,网络流量的发送者必须了解这些政策才能完成其所需的路径。
  • 建立和维护网络或子网的“隐性”成本是不可忽略的,因此必须在预算中注明,以避免出现巨大的缺口。
  • 如果一个系统假设一个同质网络,那么它可能会导致与前三个谬误相同的问题。

参考:

微服务关注点

  • 配置管理
  • 服务发现和负载均衡
  • 弹性和容错
  • API管理
  • 服务安全
  • 集中式日志记录
  • 分布式追踪
  • 调度与部署
  • 自动扩展和自我修复
  • 服务网格

微服务关注点

参考:

微服务的十诫

  1. 无状态服务和有状态服务的清晰分离
  2. 不要共享库或 SDK(依赖关系会害死你)
  3. 避免主机亲和性
  4. 专注于服务,牢记一项任务
  5. 使用轻量级消息协议进行通信
  6. 设计明确的入口点和出口点
  7. 实施自我注册和发现机制
  8. 明确检查规则和约束
  9. 更喜欢多语言而不是单栈(我们真的需要吗?)
  10. 维护独立的修订和构建环境

https://thenewstack.io/ten-commandments-microservices/

微服务和团队

(再次)“康威定律指出,设计系统的组织受限于复制这些组织的沟通结构[...]组织结构图最初反映的是第一个系统设计,而这几乎肯定不是正确的[...]随着学习的深入,人们会改变设计[...]。管理结构也需要随着系统的变化而改变……”

“逆康威策略”建议改进你的团队和组织结构,以促进你期望的架构发展。理想情况下,你的技术架构应该与业务架构同构。https ://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver

微服务应该围绕业务能力和领域进行组织

反应式编程和微服务

反应系统包括:

  • 响应式
  • 有弹性的
  • 松紧带
  • 消息驱动

驱动因素是高效的资源利用,换句话说,就是在服务器和数据中心上花费更少的钱。Reactive 的承诺是让你用更少的资源做更多的事情,具体来说,你可以用更少的线程处理更高的负载。这就是 Reactive 与非阻塞异步 I/O 的结合点所在。

Jonas Boner 认为:“微服务的响应式本质:异步通信、隔离性、自治性、单一职责、独占状态和移动性。这些是微服务的核心特征。”

微服务解决了组织问题并引发了技术问题

来自 Go + 微服务 = Go Kit [I] - Peter Bourgon,Go Kit

https://youtu.be/NX0sHF8ZZgw?t=729

解决的问题、引发的问题、吸取的教训

灵感来自“Peter Bourgon - Go + 微服务 = Go Kit” https://www.youtube.com/watch?v=JXEjAwNWays

问题解决

  • 团队规模过大,无法在共享代码库上有效工作
  • 团队被其他团队阻止 — 无法取得进展
  • 通信开销太大
  • 速度停滞
  • 赋予技术更多自由和替换能力
  • 不同时区的团队
  • 可扩展性和一些技术问题

造成的问题

  • 需要明确定义的业务领域才能提供稳定的 API
  • 如何使其解耦?
  • 不再共享数据库——分布式事务?
  • 测试变得非常困难(有人会遇到混乱的猴子吗?)
  • 需要开发/运维文化:开发人员部署并运维他们的工作
  • 作业(服务)调度 — 手动工作,一段时间内……
  • 可寻址性,即服务发现
  • 监控和仪表 — tail -f?Nagios 和 New Relic?
  • 分布式追踪?
  • 您的 SLA?
  • 审计?
  • 生产数据库快照
  • 代码重用

经验教训

  • 分布式系统很难实现
  • 进化架构!
  • 微服务正在改变组织
  • 需要 Devops/SysOps 技能,需要高水平自动化
  • 只是另一个复杂程度
  • 始终检查你的框架是否已经解决了你的问题
  • 代码重用可能很难(或者你只是不想这样做)
  • 异步通信/事件源可能有助于解耦
  • 配置/发现应该从第一天就存在吗?
  • 每个微服务一个团队?
  • 进入 Micro 之前请三思
  • 微服务解决了组织问题,却引发了技术问题
  • 业务需求未知,Micro难以管理,正确的分割线在哪里?
  • 使用开源软件是可行的方法吗?
  • 先从微服务开始?先单体应用,再微服务
  • 软件公司 - 不确定他们是否有可能做这样的事情 - 上市时间?
  • 一个团队和微服务? - 不。
  • 创建分布式单体应用很容易
  • 默认情况下的“分布式”工具也很难
  • 注定失败

通过错误的决策,你可以开发出:Kelsey Hightower 的“分布式单体应用程序:一个伪装成微服务集合的单体应用程序,使用 JSON 拼接在一起,同时写入单个数据库”

参考

内部沟通和 REST 与消息传递

微服务之间的通信需要基于异步消息传递(而每个微服务内部的逻辑则以同步方式执行)。如前所述,为了在时间上(允许并发)和空间上(允许分布和移动)解耦服务及其通信流,服务之间必须存在异步边界。如果没有这种解耦,就不可能达到隔离和弹性所需的隔离和包容级别。

异步非阻塞执行和IO通常通过更高效地利用资源来提高成本效益。它有助于最大限度地减少系统中共享资源的争用(拥塞),而争用(拥塞)是实现可扩展性、低延迟和高吞吐量的最大障碍之一。

Jonas Boner 认为,“同步 HTTP 被广泛视为首选的微服务通信协议,这很不幸。它的同步特性会导致服务间强耦合,使其成为非常糟糕的服务间通信默认协议。”

微服务反模式和陷阱

微服务常见错误:

微服务故事

Netflix

  1. https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/
  2. https://medium.com/refraction-tech-everything/how-netflix-works-the-hugely-simplified-complex-stuff-that-happens-every-time-you-hit-play-3a40c9be254b
  3. https://www.infoq.com/news/2019/01/netflix-evolution-architecture/

亚马逊

https://www.slideshare.net/adriancockcroft/microservices-workshop-craft-conference

eBay 和 Google

  1. https://www.slideshare.net/RandyShoup/from-monolith-to-microservices-craftconf-2015 https://www.slideshare.net/kasun04/microservices-at-ebay
  2. http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html
  3. https://www.infoq.com/presentations/google-microservices/

领英

  1. https://www.infoq.com/presentations/linkedin-microservices-urn/
  2. https://www.slideshare.net/InfoQ/from-a-monolith-to-microservices-rest-the-evolution-of-linkedins-service-architecture
  3. https://engineering.linkedin.com/architecture/brief-history-scaling-linkedin

叽叽喳喳

  1. http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html
  2. https://www.infoq.com/articles/twitter-java-use/
  3. https://blog.twitter.com/engineering/en_us/topics/infrastructure/2017/the-infrastructure-behind-twitter-scale.html
  4. http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

扎兰多

  1. https://jobs.zalando.com/tech/blog/jimmy-to-microservices-the-journey-one-year-later/?gh_src=4n3gxh1
  2. https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando/

Spotify https://www.kevingoldsmith.com/talks/microservices-at-spotify.html

百思买https://blog.runscope.com/posts/monolith-microservices-transforming-real-world-ecommerce-platform-using-strangler-pattern

Wix https://stackshare.io/wix/scaling-wix-to-60m-users-from-monolith-to-microservices

Airbnb https://thenewstack.io/airbnbs-10-takeaways-moving-microservices/

Tumblr http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html

沃尔玛https://www.slideshare.net/kvnwbbr/revitalizing-walmarts-aging-architecture-for-web-scale

参考

Docker 在生产环境中

文章来源:https://dev.to/kgoralski/deep-dive-into-microservices-architecture-h54
PREV
如何在 Mac 终端上设置 ZSH
NEXT
React Dashboard 终极指南。第一部分:概述和分析后端