在讨论微服务时，经常出现有关软件架构的问题。许多微服务的新手不确定如何讨论架构以及如何做出决策。本文将解答这些问题，并分享一些其他建议。
整个系统的高级视图
首先，无论您决定什么是处理架构决策的好方法，您都需要知道您的系统是什么样的。
我从事过一些项目，其中真正的架构是“部落知识”，从一组开发人员传递到另一组开发人员，以及最新的高级逻辑架构图是一个贴在墙上的系统。
为了真正做出精确的架构决策并重构您的系统，您真的需要知道您正在使用的是什么。进入“盲目”状态很容易犯错并忽视副作用和依赖性。
我的第一个建议是，无论你决定什么 - 首先要在创建高级逻辑架构图方面付出一些努力。理想情况下，您还可以为数据流，安全性和系统的其他重要方面制作一些图表。
使用图表工作可能看起来像是一件苦差事，所以请确保与那些对团队有重要且真正有用的人一起工作。
架构选择
是什么让微服务系统的架构更难以讨论？我相信这将是这两件事：
- 快速变化
- 每一步都有很多选择
随着每一步的选择数量增加，你不能只相信自己的运气而不去考虑细枝末节。此外，随着开发的快速推进，你应该远离TOGAF等类似的想法。（根据我的拙见，你应该远离TOGAF）。
使用架构决策记录作为系统设计工具
架构决定（AD）是一种软件设计选择，针对功能性或非功能性的需求进行的选择设计。（ADR GitHub组织的主页）
ADR并不是全新的--Michael Nygard已经在2011年的博客文章中对它们进行了描述，但我仅在2018年与他们联系。在2002年，ThoughtWorks将其作为技术采用雷达列为ADOPT级技术。
这整个想法是什么？有不同的方法，但它大致归结为：
- 对于您将采取的每个建筑决策（AD），请遵循此流程。
- 对于每个AD，使用模板记录：
- 上下文
- 动机
- 决策
- 状态
- 后果
- 上述组合（或其他要求）
- 这些创建ADR（建筑决策记录）
- 将它们存储在像Git存储库，Google文档，Wiki（适用于您的团队的东西）的地方
这里的核心思想是保持简单，保持标准化，保持可访问性。
我相信对于许多团队来说，这正是我们所需要的。你想知道决定了什么，何时以及为什么。这不需要花费太多精力。
将这个想法更进一步并使用Git-您可以将架构决策作为人们讨论的拉取请求。让更多人参与和听到的好方法！
分布式系统的稳定性
由于构建像微服务这样的分布式系统比较难，我建议在引导整体架构和设计时添加一种额外的，更微妙的技术：消费者驱动合约Consumer Driven Contracts（CDC）。
如果您不熟悉这个概念，请查看 https://docs.pact.io/ ，在那里您可以阅读Pact（一种流行的CDC工具）的介绍。
如果您以真正的分布式方式（多个团队，多个服务）工作，您需要找到一种方法让其他团队了解对您和您的系统来说具有架构意义的东西。一种方法是使用普通的ADR，另一种方法是使用CDC。
需要传统的软件架构师吗？
我认为很明显，在使用微服务时，您需要考虑软件架构。您还应该参与架构决策（在ADR的帮助下）并发展您的API（安全地使用CDC）。
这是否意味着你需要一位架构师？做：
- 更新高级架构图
- 帮助创造和进步ADR
- 致力于跨团队的API设计
- 与团队一起解决更具挑战性的问题（安全等）
我认为在一个足够大的项目上这四点可以是一个人的一份全职工作。你不一定需要有这样头衔的人，但你肯定需要拥有架构技能的人。
总结
希望本文能够让您了解如何在微服务系统中实现架构工作。在微服务上工作比仅仅构建巨石单体更困难。这意味着您不仅需要一个优秀的开发团队，还需要具有敏锐架构直觉和现代轻量级工作的人才能工作！