微服务很难——微服务的无价指南。
微服务很难——微服务的无价指南。
如果你想迁移到微服务，我有一些非常有用的建议给你，这是我们在从整体迁移到可扩展、可维护的微服务架构的过程中学到的。
背景
18 个月以来，我们一直在构建我们的平台。开始时相对简单。我们有一个小型 go 服务器(使用 Gin )和一些 REST 端点。它看起来有点像这样。
https://oursite.com/api/v1/places
https://oursite.com/api/v1/users
https://oursite.com/api/v1/bookings每个资源都有自己的版本 URL。他们将各自支持岗位，获取，补丁，必要时删除。我们有两个独立的移动客户端连接到这些 API，我们有一个集中的数据库。我们使用 JWT 进行用户认证，一切进展顺利。我们每小时处理相当多的请求。然而，我们需要改变我们的平台。移动应用程序不太好用。
这是我们开始遇到问题的地方。我们有大量涉及 2 个 web 应用程序的新需求。有两个选择，其中只有一个是可行的。我们可以重写我们的整个架构，花几个月的时间编写一个具有所需功能的新服务器，或者我们可以使用现有的服务器，并为其添加新功能。考虑到时间限制，我们使用了现有的服务器。
几周后，我们的遗留代码已经开始增长，我们开始遇到问题。改变模式变得越来越困难，一切都像是一件苦差事。我们坚持不了多久，来到了另一个路口。我们现在的选择是:继续构建当前的服务器，在扩展时遇到困难的问题或者迁移到一个更具可扩展性和可维护性的方法。一颗银弹，如果你愿意的话。
什么是微服务？
无论如何想象，微服务都不是银弹。谈到软件开发，我不相信有什么灵丹妙药。如果有人告诉你有，要持怀疑态度。基本上，微服务做到了他们在铁皮上说的话。它们是小型的、孤立的服务，代表了你的业务领域的一小部分。
对于微服务应该如何工作和通信，每个人都有不同的看法，但有些信念比其他信念更普遍。说它们简单是一种保守的说法。微服务架构的概念简单而理想。最初的处决？远非如此。
Monolithic vs Microservice — courtesy of https://www.weave.works
上图解释了单片架构和非常简单的微服务架构之间的区别。使用单一架构，您有一个大型服务器负责处理所有请求。这会让你大吃一惊。这会给你很大的打击。然而，微服务可以根据您的业务需求平衡流量。如果您收到大量付款，您可以扩大您的付款服务，并保持其他服务使用较少的资源。这是水平缩放的最佳表现。
微服务听起来很棒，为什么很难？
微服务非常理想化，你会听到相对较少的大公司宣扬其好处。我觉得好像很多小公司错误地把这些信息当成了福音。这些大公司如优步、谷歌、 AirBnb 、 Square 等等之所以能做好微服务，是因为它们绝对负载。他们有资源和时间来投资构建这个架构。
当你开始研究微服务时，你进入了一个绝对巨大的兔子洞。它让《爱丽丝梦游仙境》看起来像个穿洞。您很快就会了解到，您需要管理所有这些微服务并平衡负载，同时监控正在发生的一切。哦，不要忘记，当您构建新功能时，您需要在本地测试每个服务。
经过几周的研究和测试，这里有一个我推荐研究的每个服务和工具的责任清单
看看这个列表，对于一个简单的服务来说，这是一个很大的负担。然而，能够监控服务之间的交互并编排它们是非常强大的。这里面有些术语可能会让人困惑。我会涵盖最令人困惑的。
边缘代理 —边缘代理是一个与您的服务并行运行的进程，它通过自己的内部系统代理您的服务流量，通常使用某种中间件(如 prometheus)来监控和跟踪该流量。大使是建立在特使，并提供更多的功能。
集装箱——你现在很可能听说过 Docker。这是网络上的容器标准。这实际上是对“容器”一词的一种玩法。您可以考虑 docker 容器和小型运输容器，它们在云中运行您的应用程序，并由 orchestrator 移动和优化它们。他们还直接使用 linux 容器。
配器 — Kubernetes 是最受欢迎的配器，它与 Docker 配合得非常好。它本质上使用你的 docker 容器，并照看它们以确保它们都以一种有效的方式工作。
我听说我可以在每个微服务中使用任何语言，是这样吗？
确定。你可以为微服务使用任何语言，就像你可以穿着靴子跑马拉松一样。这是可能的，但并不意味着它是有效的，你可能是在浪费时间。创建稳定且可扩展的微服务架构的关键是确保它是可维护的，并且符合您企业的总体趋势。
你的架构应该有坚实的基础。如果有人参与你的项目，你应该能够说:
通常，我们的服务是用{主语言}编写的。他们使用以下框架:{框架列表}。如果你认为一项服务应该使用不同的语言，你将负责确保它与我们现有的服务具有相同的功能。
这保持了项目的一致性。当然，也有例外。如果您有一个执行复杂数学运算并处理大量流量的服务，那么您可能希望选择一种更适合该任务的语言。然而，这不是一项简单的任务。如果您在 PSL(主要服务语言)中有依赖项，那么在新语言中重新构建这种依赖项可能需要时间。
微服务如何沟通？
过去微服务的主要问题之一是延迟问题。在多个服务之间发出多个 HTTPS 请求可能会给客户端带来相当明显的延迟。这不是一个可行的方法，当然也不是轻量级的。
微服务需要一种新的方法，于是我们的救星来了: gRPC 。gRPC 是一个高效的 RPC 框架，它的设计考虑了速度和效率。二进制数据通过线路高速发送，同时还有快速的序列化/反序列化。
使用 gRPC，您可以使用一个 protobuf 定义来定义您的模型，这相当简单，并且他们有一个用于许多常见语言的 protobuf 编译器。使用 gRPC 平息了对延迟的担忧。
然而，使用这些 protobuf 模型会带来一些困惑。版本化。过去几周我们一直在研究这个问题，想知道不同的服务如何共享相同的 protobuf 模型(例如，一个用户模型)。我们有一些想法，比如将 protobuf 模型保存在一个版本化的 git 存储库中，但是我们没有被说服。我们目前正在研究这方面的最佳机制。
使用 gRPC 也有问题。您可能还需要维护一个标准的 REST API，供标准的 web 客户端访问。我们正在使用 envoy 和 grpc-gateway 在这方面取得进展。这仍然是一个复杂的问题，在微服务领域似乎没有得到太多的报道。
迁移
如果你正在考虑构建一个微服务架构，我不建议你这么做。你将花费太多的时间对你并不真正了解的域名进行不成熟的优化。要创建一个可靠的微服务架构，你需要确切地知道你为什么要这么做，没有人能真正告诉你。
然而，如果你已经有了一个整体，你正在寻找迁移，这里有一些建议。
- 确定你的业务领域(有界环境)
- 彻底研究 Docker，Kubernetes 和特使
- 研究监控和测试工具
- 花大量时间制作演示
这是我们的亲身经历。我们花了很多时间在谷歌云平台上，用新工具创建不同的架构，发现什么最适合我们。我们目前使用以下堆栈:
Primary Service Language: Go
Primary Service Datastore: Postgresq
Cloud Platform: Google Cloud
Containers: Docker
Container Orchestration: Kubernetes
Edge Proxy: Envoy
Local Testing: Telepresence
Monitoring: Prometheus
Management: Forge完成迁移经历了令人兴奋的几个月。这很难。然而，最近我们偶然发现一家公司打破了构建微服务架构的复杂门槛。他们创建了许多工具来帮助您开始使用微服务，通过我们有限的经验，我们很喜欢使用它们。该团队也非常尊重，知识渊博，反应迅速。
给他们点爱在 https://www.datawire.io 。看看他们的产品，通读他们的文件。你会对微服务有更多的了解。
我很想知道你的想法，并感谢你对这个话题的想法。如果你能从你的经历中给我们一些建议，请告诉我。我也很乐意回答任何关于我们经历的问题。