martin fowler

我刚刚在XConf上观看了Martin Fowler关于微服务的演讲。 这是我的一些笔记和相关想法。 该演讲主要基于Martin Fowler和James Lewis的有关微服务的文章 ，因此您可以在此处找到并阅读大多数信息。

视频链接： http : //www.thoughtworks.com/talks/software-development-21st-century-xconf-europe-2014

微服务的特征

Fowler在他的文章中定义了大多数已经存在的微服务架构所实现的一些特征。 在演讲中，他讨论了其中一些：

通过服务进行组件化–真正的组件是什么？ 该术语经常弹出，作为模块或小部件的“凉爽”替代品。 但是有一个模糊的定义：它是一个类，还是一个可执行文件？

从福勒的角度来看，最好使用一些现实世界的范例，例如用户如何指代“立体声系统”。 他们四处移动，将其连接到其他地方。 移动，卸下和连接其他扬声器。 基本上， 组件是可以独立升级和替换的组件 。 关于如何使用组件或将组件引入项目的主要方式：通过库（jar，gem，node_modules等）或通过服务。 区别只是服务不是直接带入您的代码库中，而是通过远程调用来调用。

围绕业务能力进行组织–团队和人员的组织非常重要。 许多组织围绕技术构建他们的团队： UI专家 ， 中间件团队 ， DBA 。 相反，对于微服务，应该围绕跨职能团队中的业务能力来组织人员：例如“运输团队”，“订单团队”，…

根据亚马逊的说法，这些团队应该是最大的角色，我们能够为他们提供2个（美国）披萨（一打）。 Fowler强调了一个重要的事实，即这些团队与最终用户或客户建立了直接的沟通渠道 ，并根据反馈获得他们所使用的建物如何被使用以及其工作状况如何。 微服务更多地是关于团队组织而不是软件架构。 架构和团队组织始终紧密地耦合在一起。

设计系统……的组织被限制生产设计，这些设计是这些组织的通信结构的副本– 康韦定律

智能端点和哑管道-使用ESB之类的智能网络基础结构是常见的做法，其中包含有关如何处理某些网络消息以及如何路由它们的逻辑。 相反，微服务促进了哑管道和智能端点/应用程序 。 问题在于智能管道（即ESB）会导致持续交付的问题，因为它们不容易被版本控制或集成到大型管道中。 此外，它会与应用程序本身建立依赖关系，这意味着当您决定升级端点/服务时，通常还必须在ESB上做一些工作。

分散数据管理–通常，在整体系统上，有一个巨大的数据库，用于存储所有数据。 通常，甚至有多个整体连接到同一个DB。

在面向服务的方法中，每个服务都有自己的数据库，并且数据不会直接与其他人共享 。 共享必须经过包装数据的服务。 这可以在服务方面带来很多有益的灵活性，因为它可以决定采用哪种技术，哪种DBMS系统等。通过这种方式，可以在服务之间使用不同的编程语言和数据库系统。 这是分散决策 。

基础架构自动化–持续交付以及用于机器配置，部署，测试等的自动化机制都是必须的。

为失败而设计–您不可避免地必须为失败而设计，因为微服务会失败，甚至经常失败。 Netflix以将其发挥到极致而闻名。 他们有一个“混乱的猴子” ，白天会在生产系统上运行，并会随机关闭服务。 这为他们提供了有关其服务的抵抗力，从中断中恢复的程度以及整个系统如何受到影响的宝贵反馈。

尽管许多人倾向于抽象化和隐藏远程呼叫，但是您不能期望他们像正常呼叫一样执行 。 期望他们失败而不是成功。 Netflix发布的一个值得注意的库是Hysterix ，它是一个延迟和容错库，旨在隔离对远程系统，服务和第三方库的访问点。

谈话中没有明确提到的其他特征是：

• 产品不是项目
• 分散治理
• 基础设施自动化
• 进化设计

您可以在Fowler网站上的微服务文章中找到有关它们的说明。

微服务真的只是SOA吗？

我也提出过几次自己的问题。 关键是-并且Fowler也提到了-定义SOA的方式。 如果将SOA视为ESB，则是智能集中式管理，在这种情况下，微服务是非常不同的。

Fowler将其定义为SOA的一个子集，它是指实现某些概念的一种特定样式。 以“微”为名，就产生了关于服务应该多大的问题？ 实际上有很多变化，从15个人-> 10服务到4个人-> 200服务。 目前尚不清楚。

何时使用Monolith和微服务？

福勒立即强调指出，对于每个新概念，人们都倾向于过度使用它。 所以要谨慎一点。

整体式

• 简便性：考虑到分布式服务是巨大的复杂性助推器
• 一致性
• 模块间的重构要容易得多。 在微服务架构中，如果您无法进行良好的服务削减，则很难转移逻辑。

微服务

• 部分部署
• 良好的可用性（如果实施了良好的故障管理）
• 保留模块化：编程语言不利于保持系统的模块化，因为它太容易逃脱其结构（如包和名称空间）
• 诸如此类架构的多种平台为诸如OS，编程语言等技术选择提供了更大的灵活性。

你一定很高...

…使用微服务。 正如Fowler有关先决条件的文章中已经提到的那样，您应该满足以下先决条件：

• 快速配置 ：能够在数小时而不是数天内设置新机器，以避免延迟。
• 良好的监视 ：能够快速诊断故障并将其追溯到发生的位置。 如果出现问题，您应该能够快速回滚到微服务的先前版本。
• 通过全自动管道快速部署应用程序
• 发展文化

就是说，Fowler说，当他不确定自己仍然喜欢Monolith结构并最终在开发周期的后期发展到微服务系统时（尽管那可能不是完全理想的）。

结论

谈话以某种方式证实了我到目前为止的印象...

• 各个级别（基础架构，测试，开发，部署）的高度自动化
• 增强团队力量，在决策中承担责任和灵活性的趋势（与敏捷已经培养的能力兼容）
• 实施最佳实践（容错，智能端点，监视，测试）
• 知道取舍，不要过度使用

作为一名建筑师和技术爱好者，这是我梦想中的建筑。 但是考虑到我在指导团队时经常遇到的问题，采用良好的编程习惯和严格的组织结构的困难……然后采用微服务架构非常困难 。

尽管如此，即使您还没有准备好，我认为您也应该针对这种结构，而不一定要全盘考虑。 就像通过遵循微服务体系结构中的实践来构造您的应用程序或产品一样，但是将其作为整体部署。 我正在考虑一个模块化体系结构，良好的故障处理，日志记录和监视，自动化的部署管道以及高度的自动化测试。 从那里开始，逐步优化。

翻译自: https://www.javacodegeeks.com/2015/01/notes-microservices-by-martin-fowler.html

martin fowler