微服务——选择的架构

微服务体系结构与更传统的单块开发风格的区别在于必须做出的选择的数量。您将使用哪些框架(如果有的话)?如何处理配置,编制或编排等等。它可能觉得不知所措。在这篇文章中,我将给你一些建议如何处理这个架构的选择有信心和成功。

我喜欢有多种选择，并对架构做出决定。对于一些人和项目来说，这是一件可怕的事情。不一定要这样。在这里给出的建议中，您可以把握自己的选择，把握自己的想法。

知道什么是可能的

有一件事让人害怕，那就是他们必须知道所有的事情，每一个框架。你不需要学习每个框架，但你需要了解它们。

我的意思是，你不需要知道如何使用Spring, Microprofile, Vert.X, Dropwizard和更多……但如果你了解它们，会对你有所帮助。它们是什么，它们的利弊是什么?

无论何时，当您面对一种消息传递技术、框架、身份验证解决方案时，不要试图学习所有的东西，而是尝试去了解所有的东西。知道它都有哪些内容和它可以用于什么。

提醒一下——如果你正在考虑一项技术，一定要确保你选择的东西至少是比较受欢迎的，而且是有前途的。你可以做一个快速的谷歌搜索，看看人们是否在写博客，查看他们GitHub上的网站上的星星数量等等，除非你完全知道自己在做什么，否则尽量避免一些非常小的项目。

我喜欢把微服务看成是一种美丽的景观，这样他们就不会那么吓人了

乐于接受新想法

要想知道什么是可能的，就必须保持开放的心态。我们开发人员喜欢对技术抱有虔诚的态度，我认为这样的想法不会让我们走得太远。

我曾经写过作为一个软件开发人员谦逊的重要性。简而言之——不止一次，我拒绝了更好的解决方案，因为我只是认为我知道得技术更好，现在我想法比以前变得更开明。

microservices仍然相对较新,人们不断挑战现状和带来新的想法。听他们说的建议，你可能会找到更好的解决方法。

避免常见的陷阱

如何做正确的事情有很多选择——成功的方法有很多。当然，也有一些方法会让你和你的项目走向失败。

来自其他体系结构样式，我们很容易犯类似的错误。基于我以前的经验(作为一名技术顾问的好处之一)，我写了一份微型服务中常见的技术债务（技术负债，指的是为了实现客户的某个需求，而做出的一种短期见效快，长期有伤害的，在技术层面的决定。）列表。

无论何时在体系结构的特定部分上工作，请确保您熟悉常见的缺陷和最佳实践。这里的共识往往比具体的技术选择要多。

架构和领导力——共享的选择

微服务背后的一个想法是让软件团队拥有这项服务。这意味着拥有实现、测试并常常在生产时为服务提供支持。

DevOps文化，这并不意味着不需要一个整体架构，或者仅仅是团队的内部利益。在服务之间进行深思熟虑的集成有巨大的好处。应该了解服务应该如何合作。

比如说，如果一个服务使用Kafka，另一个使用RabbitMQ，而第三个服务则试图在Spring云数据流之上构建一些东西——混乱就会随之而来。一些选择应该共同的选择。

这是架构师和技术人员介入的地方(即使他们没有这些头衔——我们知道你是谁!)。如果您认为您将要做出的决定将会影响到许多团队和服务——那么就让它成为一个共享的选择吧。

我认为架构师主要负责提供这种架构建议，并与团队一起工作。技术领导的角色是为团队外部可能看不到的关注点提供可见性。

选择的架构和第二次机会

有一件事应该让你在做这些选择时更加冷静，那就是你也会有第二次机会。我没见过麻烦缠身的单体架构应用成功地转化为伟大的项目……我已经在微服务上看到了这一点。

我曾见过人们在如何处理配置、改变对安全性的看法、将一项服务分解为许多其他服务以及如何生存等方面犯过重大错误。对于微服务，范围总是有限的，您确实会有第二次机会。

如果你知道没有什么决定是永远的，你可以选择现在有效的方法，而最坏的情况下，你可以用它来替换它。在冒险方面，它确实是一个游戏规则的改变者。

跟踪你的技术债务。有了微服务，您将有机会解决它。

Microservices蓝图

你不必自己去做所有的选择。毕竟，这种架构风格并不是全新的。您可以基于成功的实现和微服务蓝图来建模您的体系结构。

我是Spring生态系统的忠实粉丝，它以Spring Cloud提供的形式提供了这样的蓝图。我已经在这个博客的蓝图中回顾了Spring Cloud。

如果你正在构建一个基于框架的系统，看看其他人做了什么，很多公司，包括著名的微服务公司Netflix，都对微服务的发展非常公开。你可以根据别人的成功经验做出选择。

总结

微服务体系结构确实是 the Architecture of Choices。是坏的吗?在我看来,没有。如果你不习惯的话，这是很有挑战性的。这些挑战带来了机遇。

我希望通过阅读这里给出的建议，你能更有策略地、更有信心地面对这些选择。