什么是微服务？

了解微服务设计的内涵和外延。

受到Netflix和Amazon等科技巨头的喜爱，微服务已经成为现代软件开发的新宠，尽管它们已经有十多年的历史。但是，尽管有这些好处，这种模式也很容易出错。因此，让我们探讨一下什么是微服务，更重要的是，它们不是什么。

什么是微服务？

微服务架构是一种软件设计方法，它将一个应用程序分解成独立的小服务，通过定义明确的API进行通信。由于每个服务都可以由自主团队开发和维护，所以它是最可扩展的软件开发方法。

微服务vs.单体

微服务设计与单体开发截然相反。单片机是一个大的代码库（"厨房水槽"），实现所有功能。所有的东西都在一个地方，没有一个组件可以孤立地工作。这意味着，应用程序必须作为一个整体进行测试。

从正面看，单体系统很容易启动和运行。举个例子，Airbnb从"单轨列车 "开始，这是一个Ruby on Rails单体。虽然公司还很小，但开发人员可以快速迭代。由于单体的不同部分之间的关系是透明的，所以做出广泛的改变很容易。

然而，随着公司的发展和团队规模的扩大，单体开发变得更加困难。很快，系统就不能再装在一个脑袋里了--有太多的移动部件，所以事情就慢下来了。

微服务使公司能够保持小规模和敏捷的团队。其想法是将应用程序分解为小型服务，这些服务可以由紧密结合的团队自主开发和部署。

微服务的好处

可扩展性

公司采用微服务的主要原因是可扩展性。服务可以独立开发和发布，无需在组织内安排大规模的协调工作。

故障隔离

拥有分布式系统的一个好处是能够避免单一故障点。你可以通过云技术将微服务部署在不同的可用性区域，确保你的用户永远不会遇到故障。

更小的团队

通过微服务，开发团队可以保持小规模和凝聚力。团队规模越小，沟通的开销就越少，合作就越好。

亚马逊用他们的两个比萨饼团队把团队规模做到了极致。意思是说，一个团队应该小到可以由两个比萨饼来养活。

选择技术栈的自由

对于单片机来说，语言和技术栈的选择从一开始就已经确定了。新的开发者必须适应过去的任何选择。

相反，每个微服务可以使用最适合解决手头任务的技术栈。因此，团队可以选择最适合工作和他们技能的工具。例如，你可以用Go或C语言实现一个高性能的服务，用Erlang或Elixir实现一个高容忍度的微服务。

更频繁的发布

由于小团队的迭代速度更快，开发和测试的周期也更短。而且，由于他们也可以随时部署他们的更新，微服务的部署频率比单体要高得多。

微服务设计的挑战

微服务的设计属性

有了这么多好处，在新项目中选择微服务似乎是不费吹灰之力的。但是，微服务设计也伴随着一些严峻的挑战：

小：同时适用于团队规模和代码库。一个微服务必须小到可以被一个人完全理解。如果你要花超过一个冲刺的时间从头开始重写，你的微服务就太大了。
专注于一件事：一个服务必须专注于问题的一个方面或只执行一项任务。
自主性：自主性允许一个团队选择最合适的语言栈和数据模型。这通常意味着每个微服务有自己的数据库或持久层，不与其他服务共享。
与有界限的上下文相一致：在软件中，我们创建模型来表示我们想要解决的问题。有界的上下文代表了一个给定模型的限制。上下文是服务的自然边界，所以找到它们是设计一个好的微服务架构的一部分。
松散耦合：虽然微服务可以依赖其他微服务，但我们必须谨慎对待它们的通信方式。每次跨越有界的上下文时，都需要某种程度的抽象和翻译，以防止一个服务的行为变化影响其他服务。
可独立部署：由于是自主的和松散耦合的，一个团队可以在很少的外部协调或集成测试中部署他们的微服务。微服务应该通过定义明确的API进行通信，并使用翻译层来防止一个服务的行为变化影响其他服务。

当 "微服务 "不是微服务时

你怎么知道你是否在做正确的微服务设计？如果你的团队可以在任何时候部署更新，而不需要与其他团队协调，如果其他团队也可以类似地部署他们的变化而不影响你，恭喜你，你已经掌握了微服务的诀窍。

失去微服务所提供的好处的最可靠方式是不尊重解耦规则。如果我们仔细观察，就会发现微服务都是关于自主权的。当这种自主性丧失后，团队必须在开发和部署期间进行协调。需要进行完美的集成测试，以确保所有的微服务能一起工作。

即便如此，详尽的测试也不能抓住所有的问题。当有东西损坏时，耦合的服务是地狱般的调试。而当问题被发现时，修复它并不总是像回滚更新那样容易。

这些都是分布式计算带来的问题。如果你曾经使用过云计算服务，你就会知道，将服务或机器分散在许多地理位置上与在同一地点运行所有的东西是不一样的。分布式系统有更高的延迟，可能有同步问题，而且更难管理和调试。这种高度耦合的服务架构，从深层来说，其实是一个分布式的单体，两方面都很糟糕，没有微服务应该带来的好处。

如果你不能在不与其他团队协调的情况下进行部署，或者依靠其他微服务的特定版本来部署你的微服务，那么你只是在分发你的单片机。

当微服务不是最佳选择时

微服务并没有取代单片机。两者都是有效的方法。事实上，当团队还在发现他们正在构建的东西时，单体可能是最好的选择。

单片机可以说是一个项目的自然起点，因为它开发简单，迭代快，部署快，容易调试，而且对设计错误更宽容。在可扩展性成为一个问题之前，单体可以带你走得更远。

微服务是否适合你？

微服务是我们开发软件的最可扩展的方式。但它们并不是免费的午餐。它们伴随着一些风险，如果你不谨慎，很容易触犯。当团队正在成长，你需要保持快速和敏捷的时候，它们是很好的。但是，你需要对要解决的问题有一个很好的理解，否则你可能最终得到一个分布式的单体。