微服务架构模式也拒绝使用canonical schema等SOA概念。


Using a Reactive Programming Model

来自 Building Microservices Using an API Gateway | NGINX

The API Gateway handles some requests by simply routing them to the appropriate backend service. It handles other requests by invoking multiple backend services and aggregating the results. With some requests, such as a product details request, the requests to backend services are independent of one another. In order to minimize response time, the API Gateway should perform independent requests concurrently. Sometimes, however, there are dependencies between requests. The API Gateway might first need to validate the request by calling an authentication service, before routing the request to a backend service. Similarly, to fetch information about the products in a customer’s wish list, the API Gateway must first retrieve the customer’s profile containing that information, and then retrieve the information for each product. Another interesting example of API composition is the Netflix Video Grid.

Writing API composition code using the traditional asynchronous callback approach quickly leads you to callback hell. The code will be tangled, difficult to understand, and error-prone. A much better approach is to write API Gateway code in a declarative style using a reactive approach. Examples of reactive abstractions include Future in Scala, CompletableFuture in Java 8, and Promise in JavaScript. There is also Reactive Extensions (also called Rx or ReactiveX), which was originally developed by Microsoft for the .NET platform. Netflix created RxJava for the JVM specifically to use in their API Gateway. There is also RxJS for JavaScript, which runs in both the browser and Node.js. Using a reactive approach will enable you to write simple yet efficient API Gateway code.

没看懂具体怎样算是 reactive programming model

Towards true continuous integration: distributed repositories and dependencies


NetFlix 讲如何在微服务系统中 managing dependencies

To address the challenges of managing dependencies at scale, we have observed companies moving towards two approaches: Share little and monorepos .

  • The share little approach (or don’t use shared libraries) has been recently popularized by the broader microservice movement. The share little approach states that no code should be shared between microservices. Services should only be coupled via their HTTP APIs. Some recommendations even go as far as to say that copy and paste is preferable to share libraries. This is the most extreme approach to decoupling. 推崇完全不使用共享库的做法,甚至认为 copy&paste 优于 share libraries.
  • The monorepo approach dictates that all source code for the organization live in a single source repository. Any code change should be compiled/tested against everything in the repository before being pushed to HEAD. There are no versions of internal libraries, just what is on HEAD. Commits are gated before they make it to HEAD. Third party library versions are generally limited to one of two “approved” versions. 把所有代码放在一起,通过集成测试后才可以推到 HEAD .

Our approach, while still experimental, can be distilled into three key features:

  • Publisher feedback - provide the owner of shared code fast feedback as to which of their consumers they just broke, both direct and transitive. Also, allow teams to block releases based on downstream breakages. Currently, our engineering culture puts sole responsibility on consumers to resolve these issues. By giving library owners feedback on the impact they have to the rest of Netflix, we expect them to take on additional responsibility. 提供一种机制,使 shared code 的 owner 可以最快知道 consumer 挂掉了,可以 block 发布
  • Managed source - provide consumers with a means to safely increment library versions automatically as new versions are released. Since we are already testing each new library release against all downstreams, why not bump consumer versions and accelerate version adoption, safely. 使 consumer 可以自动更新 shared code 版本,前提是 code 已经针对所有下游做过测试。这是没有仔细说怎么测试,但是前文提到过契约测试“Breaking functional changes — Welcome to the world of software development! Ideally this is mitigated by proper testing. Ideally, library owners are able to run their consumer’s contract tests to understand the functionality that is expected of them.” .
  • Distributed refactoring - provide owners of shared code a means to quickly find and globally refactor consumers of their API. We have started by issuing pull requests en masse to all Git repositories containing a consumer of a particular Java API. We’ve run some early experiments and expect to invest more in this area going forward. 使 library owners 可以批量查找和修改 consumer 代码,我们目前好像还没有这种需求,人肉来吧。