rest接口案例

by RDX

由RDX

REST和平：微服务与现实案例中的整体 (REST in Peace: Microservices vs monoliths in real-life examples)

I’ve consulted on a dozen microservice projects. Some were awesome (this is the future!) and some were equally frustrating (who invented this crap?)

我已经咨询了十几个微服务项目。 有些很棒(这就是未来！) ，有些同样令人沮丧(谁发明了这种废话？)

It’s the execution that matters, not the approach. You can succeed or fail with either. Don’t just accept the love/hate propaganda out there.

重要的是执行力，而不是方法。 您可以成功或失败。 不要仅仅接受爱恨交加的宣传。

Here are some experiences I’ve had that show how both monoliths and microservices have their place.

这是我经历过的一些经验，这些经验表明了整体式和微服务式的定位。

为正确的工作选择合适的工具 (Picking the right tool for the right job)

My team built a news reader app. It had to scrape articles, extract content, classify, serve an API, show admin panel, and manage users.

我的团队构建了一个新闻阅读器应用程序。 它必须抓取文章，提取内容，分类，提供API，显示管理面板以及管理用户。

• Scrapy (python 2 at that time) is the leader when it comes to web scraping. So we created one microservice that scraped URLs. (Here’s a bit more on my 15MB Docker image with Tor, Privoxy and a Process manager if you’re curious.)

  在抓取网页时， Scrapy (当时为python 2)是领导者。 因此，我们创建了一个可抓取URL的微服务。 (如果您好奇的话，在我的15MB Docker映像中还有更多有关Tor，Privoxy和流程管理器的信息 )。

• Newspaper (python 3) is one of the best open source article extraction libraries. So we created one microservice that, given an input URL, returns the extracted content.

  Newspaper (python 3)是最好的开源文章提取库之一。 因此，我们创建了一个微服务，给定输入URL，该微服务返回提取的内容。

• R has some good libraries for categorization. A colleague with good knowledge of R put together a service for categorizing articles using R’s REST API.

  R有一些很好的分类库。 一位具有R的丰富知识的同事提供了一项使用R的REST API对文章进行分类的服务。

• ActiveAdmin is one of the best and easiest Admin panel interfaces. For a long time, we have been leveraging it for admin screens, and we hooked it up in a few days here as well.

  ActiveAdmin是最好和最简单的管理面板界面之一。 长期以来，我们一直在将其用于管理屏幕，并在几天之内将其连接起来。

• Finally for the API gateway, we used Node.js with PassportJS (for multiple auth) and ElasticSearch.

  最后，对于API网关，我们将Node.js与PassportJS (用于多个身份验证)和ElasticSearch一起使用。

Before this big re-write, our old app was a Rails monolith. It tried to reinvent everything mentioned before. You can imagine the trade-offs in code, effort, and time for quality, progress, and output.

在进行如此大的重写之前，我们的旧应用是Rails的整体。 它试图重塑以前提到的一切。 您可以想象在代码，工作量和时间上进行权衡，以获得质量，进度和输出。

Bad monoliths try to reinvent the world. They think that code and design patterns are the solution to everything. They strive to build reusable components, libraries, and also become a platform along the way. But they usually don’t end up succeeding at any of these goals.

坏的巨石试图重塑世界。 他们认为代码和设计模式是一切的解决方案 。 他们努力构建可重用的组件，库，并一路成为平台。 但是他们通常不会最终成功实现这些目标。

Takeaway #1: Microservices are a business solution, not just a technology solution. They save developers from having to waste time reinventing already solved technical problems.

要点1：微服务是一种业务解决方案，而不仅仅是技术解决方案。 它们使开发人员不必浪费时间重新发明已解决的技术问题。

I don’t care if you call them “Services”, “Service-oriented architecture”, or “Microservices.” Once we get past buzzwords, “monolith vs microservices” boils down to “1 service vs N services.”

我不在乎您是否将它们称为“服务”，“面向服务的体系结构”或“微服务”。 一旦我们克服了流行语，“整体与微服务”就可以归结为“ 1服务与N服务”。

For our application, “N services” turned out to be the stack we wanted.

对于我们的应用程序，“ N服务”原来是我们想要的堆栈。

Monster CRUD应用 (Monster CRUD apps)

Some enterprise projects can simply be categorized as monster CRUD (Create-Read-Update-Delete) apps. They’re a never ending stream of forms, data relationships, transformations, and hugely complicated “Business logic.” The scope is huge, but the audience is tiny.

某些企业项目可以简单地归类为怪物CRUD(创建-读取-更新-删除)应用程序。 它们是形式，数据关系，转换和极其复杂的“业务逻辑”之源。 范围很广，但是观众很少。

Nobody here cares about user experience best practices, and its common to have quick and ugly screens that get the job done.

这里没有人关心用户体验的最佳实践，而拥有快速而丑陋的屏幕来完成工作通常是很常见的。

We had one such enterprise transformation project. The old monolith was a database-view-based integration. It was pretty well designed, and only took a few people to maintain, including the ugly user interfaces.

我们有一个这样的企业转型项目。 旧的整体是基于数据库视图的集成。 它的设计非常好，仅需几个人即可维护，包括难看的用户界面。

The new backend services were mostly written in Java, so it was difficult to develop, integrate, share, and maintain compatibility. And new front-end services got pulled into the ever-changing world of single-page apps.

新的后端服务主要是用Java编写的，因此很难开发，集成，共享和维护兼容性。 并且新的前端服务进入了日新月异的单页面应用程序世界。

Deployment required a huge infrastructure automation setup. This was a few years ago, before the developer tooling ecosystem had matured. At the time, every contract change needed to be coordinated and updated by hand. It was the opposite of the previous scenario — the effort/output/overhead of microservices felt much bigger than that of the old monolith.

部署需要庞大的基础设施自动化设置。 这是几年前的，那时开发人员工具生态系统还没有成熟。 当时，每个合同变更都需要手动进行协调和更新。 这与之前的情况相反-微服务的工作量/输出/开销比旧的整体要大得多。

Takeaway #2: Be careful. Treating microservices as splitting code layers into docker-ized boxes can lead to “death by a thousand cuts.”

要点2：小心。 将微服务视为将代码层划分到docker化的盒子中可能会导致“削减一千人”。

驯服巨大的依赖树 (Taming a huge dependency tree)

We had another legacy enterprise application transformation which did a lot of things like product scraping and parallel aggregation. It was a complicated, already troubled monolith.

我们进行了另一个旧式企业应用程序转换，该转换完成了许多工作，例如产品抓取和并行聚合。 这是一个复杂的，已经麻烦的巨石。

When we’re doing a lot of orthogonal business features inside a single app, it causes a huge compile-time dependency tree, with tons of libraries and frameworks. Consequently, the runtime footprint, lifecycle, and build times were also long. This contributed to the real problem: developers couldn’t iterate quickly, and time-to-market of features suffered as a result.

当我们在单个应用程序中执行许多正交业务功能时，它会导致巨大的编译时依赖关系树，以及大量的库和框架。 因此，运行时占用空间，生命周期和构建时间也很长。 这导致了一个真正的问题：开发人员无法快速迭代，因此功能的上市时间受到了影响。

Time taken to code a simple feature: several days.

编写一个简单功能所需的时间：几天。

Time to upgrade a library (guice) version: 1 week.

升级库(guice)版本的时间：1周。

Time taken to upgrade a framework (Spring) version: forever.

升级框架(Spring)版本所需的时间：永远。

Trivial stuff had the chance to rip apart every time estimate. Even a small refactor took long. It turns out that death by a thousand cuts is possible with monoliths as well.

琐碎的东西每次估计都有机会撕开。 即使是很小的重构也花费了很长时间。 事实证明，巨石也有可能被一千人砍死。

We divided the project into some functional boundaries. We actively made sure to not share libraries and to avoid the dependency tree bottleneck.

我们将项目划分为一些功能边界。 我们积极确保不共享库，并避免依赖树瓶颈。

For example, we used a modern client library for publishing messages over PubSub for the microservices. But the monolith’s big dependency tree did not allow us to use the same library. So we used a different HTTP-based PubSub client.

例如，我们使用了现代的客户端库通过微服务的PubSub发布消息。 但是，整体式的大依赖树不允许我们使用相同的库。 因此，我们使用了另一个基于HTTP的PubSub客户端。

Microservices transitionists often make the classic mistake of sharing too many libraries and thereby re-create the same compile-time dependency trees (a “distributed monolith”).

微服务过渡主义者经常犯这样的经典错误：共享太多的库，从而重新创建相同的编译时依赖树(“分布式整体”)。

But by avoiding sharing functionality, we could use different libraries to accomplish the same tasks without having to upgrade the world.

但是通过避免共享功能，我们可以使用不同的库来完成相同的任务，而不必升级世界。

One of the services required a lot of concurrency (~1k lookups for every request). It initially leveraged RxJava. But it could be rewritten any day in Golang with the same API contract, and nobody would care about the dependency tree.

其中一项服务需要大量并发性(每个请求约1k查找)。 它最初利用RxJava。 但是它可以使用相同的API合约在Golang中随时进行重写，而且没有人会在意依赖树。

Takeaway #3: With microservices, you won’t hear the term “big rewrite” or “legacy system” ever again because there are no big systems.

要点3：使用微服务，您将再也不会听到“大型重写”或“旧版系统”一词，因为没有大型系统。

可扩展性神话 (The scalability myth)

My team developed a code evaluation app. It was 90% CRUD, user interface, and reports, and 10% complex code evaluation for a dozen languages.

我的团队开发了一个代码评估应用程序。 这是90％的CRUD，用户界面和报表，以及10％的针对十多种语言的复杂代码评估。

Before we came in, it was a series of microservices — one for each type of language, listening for different message queues. It had a separate front-end-as-a-service, admin-panel-as-a-service, and so on. Their original reasoning? Scalability.

在我们出现之前，它是一系列微服务-一种针对每种语言的微服务，用于侦听不同的消息队列。 它有一个单独的前端即服务，管理面板即服务，等等。 他们最初的理由？ 可扩展性。

We killed the whole thing and built a better monolith. It was completely done as a single Rails app — user interface, admin, back end, and candidate interface.

我们杀死了整个东西，并建造了一个更好的整体。 它完全通过单个Rails应用程序完成-用户界面，管理，后端和候选界面。

The code evaluation part ran as a background job (ActiveJob). We shelled this out across simple, stateless, one-off Docker containers. The core contract for evaluating code changed from REST/JSON into file/stdin/stdout. It scaled much better than the old system, because we just needed to ramp up the background workers to handle more code evaluations.

代码评估部分作为后台作业(ActiveJob)运行。 我们在简单，无状态的一次性Docker容器中添加了外壳。 评估代码的核心合同从REST / JSON更改为file / stdin / stdout。 它的扩展性比旧系统好得多，因为我们只需要增加后台工作人员来处理更多的代码评估即可。

What looked like a sophisticated application from the outside — supporting 8 major programming languages with intelligent evaluation — was extremely simple on the inside.

从外部看，这似乎是一个复杂的应用程序，它支持8种主要编程语言并具有智能评估功能，而内部却非常简单。

Takeaway #4: You don’t need microservices to run multiple instances of a service or worker. Good monoliths can also scale for some classes of problems.

要点4：您不需要微服务来运行服务或工作程序的多个实例。 好的整体设计也可以解决某些类型的问题。

It is quite possible to create scalable monoliths and unscalable microservices. It all comes down to how well you apply each’s underlying principles.

创建可伸缩的整体和不可伸缩的微服务是很有可能的。 一切都取决于您如何很好地运用每个基本原则。

微服务产品 (Microservices as products)

One of the most satisfying microservices projects I’ve worked on approached microservices as products. Our clients were extremely smart, techno-functional people, and they were clearly leveraging microservices as a business tool.

我从事过的最令人满意的微服务项目之一就是将微服务作为产品。 我们的客户是非常聪明，具有技术功能的人员，并且他们显然将微服务用作商业工具。

They modeled each service as a product, then released multiple products to different customers. They lined up the product releases in a way that each could leverage another’s APIs. In turn, they created a brilliant ecosystem. It made them a market leader in their vertical.

他们将每个服务建模为一个产品，然后将多个产品发布给不同的客户。 他们以一种可以利用彼此的API的方式来排列产品版本。 反过来，他们创造了一个辉煌的生态系统。 这使他们成为垂直行业的市场领导者。

The average enterprise today uses at least a dozen software products and integrations. The average cloud consumer uses multiple cloud products. I now see even non-technical people use micro-products and micro-apps. For example, one tool for interviewing, one for vacation tracking, one for payslips, etc. People are embracing smaller, more specialized tools that get the job done properly.

如今，普通企业至少使用十几种软件产品和集成。 平均云消费者使用多种云产品。 我现在甚至看到非技术人员也会使用微型产品和微型应用程序。 例如，一种用于面试的工具，一种用于假期追踪的工具，一种用于工资单的工具，等等。人们正在拥抱更小，更专业的工具，这些工具可以正确地完成工作。

Takeaway #5: We are strongly and firmly into the micro-products, micro-apps and micro-services era. Better learn to do it well.

收获五 ：我们坚定地进入微产品，微应用和微服务时代。 更好地学习做好。

There is this constant fear of machine learning stealing programming jobs. Most programming jobs are becoming APIs today.

人们一直担心机器学习会窃取编程工作。 今天，大多数编程工作正在成为API。

分布式交易 (Distributed transactions)

One of the most common arguments against using microservices is the risks associated with distributed transactions.

反对使用微服务的最常见论据之一是与分布式事务相关的风险。

Are you calling an external Payment gateway system that deducts money, but could fail on your callback? Do you have multiple sign-on mechanisms (like email or OAuth)? Are you calling third-party SaaS products that don’t have a rollback option? Are you leveraging Cloud APIs and storage buckets which don’t respect your transaction boundary? Do you have workflows spanning multiple request lifecycles to the same service?

您是否正在呼叫一个外部付款网关系统，该系统可以扣除费用，但可能无法执行回叫？ 您是否有多种登录机制(例如电子邮件或OAuth)？ 您是在呼叫没有回滚选项的第三方SaaS产品吗？ 您是否在利用不遵守事务边界的Cloud API和存储桶？ 您是否具有跨越多个请求生命周期到同一服务的工作流？

Then you already have distributed transactions in one way or another, whether you like it or not.

然后，无论您是否喜欢，您都已经以一种或另一种方式分发了事务。

The whole idea that one system and one request can represent or control the entire transactional state of the business problem is a fantasy. If you can model your external integrations without distributed locks and transactions, then you can model your internal ones too.

一个系统和一个请求可以代表或控制业务问题的整个交易状态的整个想法是一种幻想。 如果您可以在没有分布式锁和事务的情况下对外部集成进行建模，那么您也可以对内部集成进行建模。

Takeaway #6: Distributed locks and transactions aren’t free with Monoliths, either.

要点六 ：Monoliths也不免费提供分布式锁和事务。

工具与人 (Tooling vs People)

Yes, more services means more tooling. This involves continuous integration and continuous deployment (CI/CD), infrastructure automation, developer tooling, the ability to design good APIs, contract sharing, documentation, client intelligence and libraries, processes, testing, and a lot of other tools.

是的，更多的服务意味着更多的工具。 这涉及持续集成和持续部署(CI / CD)，基础架构自动化，开发人员工具，设计良好的API的能力，合同共享，文档，客户端智能和库，流程，测试以及许多其他工具。

You must be at least this tall to ride microservices.

要使用微服务，您必须至少高个子 。

If an organization does not have the engineering robustness and maturity to effortlessly run a handful of services (12factor, CI, CD, integration, testing, etc), it will be a disaster to switch to many of them.

如果组织没有工程上的健全性和成熟度来轻松运行少量服务(12factor，CI，CD，集成，测试等)，那么切换到许多服务将是一场灾难。

Lots of people coming from a monolith mindset do Big Design Up Front. Microservices are best when they are in-your-face. Just throw away all the boilerplate, implement the API in a no-nonsense way and instead invest time in good quality unit/contract tests. Like with tooling VS people — microservices require a change in mindset, and a great deal of unlearning.

来自整体思维方式的许多人都在前面做大设计 。 当您面对面时，微服务是最好的。 只需丢掉所有样板文件 ， 以轻松的方式实施API，然后将时间投入到高质量的单元/合同测试中即可。 就像使用VS人员一样，微服务需要改变思维方式和大量的学习不足 。

The good news is that many of these tooling problems have good engineering solutions. Docker, Kubernetes, REST, Swagger, Falcor, gRPC, CI/CD Pipeline tools, PaaS, Cloud, and so on. The ecosystem around microservices has already matured quite a bit, and its improving all the time.

好消息是，其中许多工具问题都具有良好的工程解决方案。 Docker，Kubernetes，REST，Swagger，Falcor，gRPC，CI / CD管道工具，PaaS，云等。 微服务周围的生态系统已经相当成熟，并且一直在不断完善。

The bad news is that microservices can’t be learned like a framework or tool. They require a holistic approach that comes with experience. You need good people who are not only brute-force good coders, but also well-rounded engineers with a strong foundation in the whole software development lifecycle, from development to testing to deployment.

坏消息是无法像框架或工具那样学习微服务。 他们需要具有经验的整体方法 。 您需要的人才不仅是强力的优秀编码人员，而且还是从开发到测试再到部署的整个软件开发生命周期中具有坚实基础的全面的工程师。

There are big enterprises that take months for every single integration. And then there are modern companies like Google, Facebook, and Netflix that run thousands of integrated services at a far greater quality and speed. The difference isn’t just the tools — it’s the people involved and their engineering approach.

每个大型集成企业都需要花费数月的时间。 然后，还有像Google，Facebook和Netflix这样的现代公司，它们以更高的质量和速度运行数千种集成服务。 不同之处不仅在于工具，还在于所涉及的人员及其工程方法。

Takeaway #7: Microservices are a culmination of multiple engineering practices. They have a steep curve of learning, unlearning, and transformation.

要点7 ：微服务是多种工程实践的结晶。 他们的学习，学习和转变都非常艰难。

结论 (Conclusion)

The microservices approach is just another tool in the solutionist’s toolkit. And a tool is just a tool. It can end up being a powerful business asset, or an unproductive developer bottleneck. Whether we’re right or wrong all comes down to how we use this tool.

微服务方法只是解决方案工具包中的另一个工具。 工具只是工具。 它最终可能成为强大的业务资产，或者成为无效的开发人员瓶颈。 无论是对还是错，都取决于我们如何使用此工具。

翻译自: https://www.freecodecamp.org/news/rest-in-peace-to-microservices-or-not-6d097b6c8279/

rest接口案例