Exciting micro-Service 2.0 technology stack

This is a creation in Article, where the information may have evolved or changed.

Author |christian

Edit | Zhuo Demure

Today's market is changing rapidly, new technologies are emerging, and micro-services continue to be hot. If 2014 is the day of the MicroServices, then 2015 and 2016 are the moments when microservices go down the altar, and more and more developers and architects are discussing how to land, how to solve various practical problems, and many technology stacks and tools are emerging.

When we built our microservices, we were really deeply involved in the analysis of distributed systems-a technology topic that has been researched for more than 40 years, and complex adaptive systems theory has been popular for a long time. From a technical point of view, we need to solve the following things:

• deployment

• delivery

• api

• versioning

• contract

• ZOOM/auto-scale

• service discovery

• load Balancing

• route/Adaptive Routing

• Health check

• configuration

• fuse

• bulk-heads

• ttl/deadlining

• delay tracking

• service causality tracking

• distributed log

• measure operations and collection

Netflix and some internet companies as adopters of early micro-services have made a lot of investments, attempts and contributions in these areas (such as open source tools and related papers). "Micro service is not a free lunch". Companies are not all Netflix, the complexity of micro-services and the cost of bringing a lot of companies to deter, blocked in the door.

Today, as more and more businesses and communities join the ranks, with the early adopters ' sedimentation and the co-creation of successors, a new wave of solutions and technology stacks are emerging in many known problem areas of microservices, giving them new hope. Recently, Christian Posta published an article titled "Exciting Micro-service technology Stack 2.0" to illustrate this trend. He pointed out that the advent of these technology stacks can help solve many of the problems that have existed or are difficult to cross in some problem domains, and can even be solved more gracefully.

The first example mentioned by Christian is kubernetes. He noted that:

Google and Red Hat are the third time to build a platform with application-level primitives using Kubernetes, a platform for running native cloud applications built on containers. There have been different attempts by Google or the open source community in the past, but kubernetes greatly simplifies tasks such as service discovery, scale-up, deployment, and so on. It seems that the rest of the community agrees that Kubernetes is the hottest item on GitHub and now has more than 1000 submissions, which is crazy. If Kubernetes appeared 5 years ago, you wouldn't see so many "microservices" frameworks to solve these problems.

Another example Christian mentioned is the fusing. A microservices architecture consists of multiple independent services, which, if any of the services fail, can cause other dependent services to fail in the same way as dominoes, resulting in a complete system paralysis. This makes it one of the most important issues to ensure the stability of services and services in a framework such as microservices. And the fusing mechanism is a model to solve this problem.

The fusing mechanism refers to the failure of a circuit breaker to return a timely error response to a call, rather than a long wait, in the event of a service failure. This will not cause the thread to be occupied for a long time because of the call failure, thus avoiding the spread of the fault throughout the system.

In the development of fusing technology, Christian talked about:

In anyone can write a fuse (and many have). Netflix even released their fuses (Hystrix library). Applications can use the Hystrix library to implement related functions. However, when it comes to fusing, service discovery, tracking, metrics, and other problems, it relies heavily on developers getting the right class library and really doing it. This is very difficult. We need a new way to solve this problem.

Christian that "What we really want is not more class libraries or frameworks that make our applications more complex, but rather that each developer can use or apply them correctly between projects, or even more importantly, regardless of the programming language." Maintaining a different implementation of a class library can be a crazy one. He points out that there have also been some "more elegant" ways in the field, such as IMHO and envoy project from Lyft.

IMHO put these issues on the client agent, which is deployed as a "bucket" of applications. Envoy is a very small C + + client Agent that handles issues such as fusing, batch stacks, service discovery, Measure collection, tracking, and more. This means that a single envoy agent will be deployed with each application (1-1). The application can take advantage of this functionality without having to consider the constraints of the programming language. The application basically communicates with other services through "localhost", envoy all the agents that complete the service work. It knows how to find back-end services, complete adaptive routing, retry, tracking, tuning and other tasks. Developers can keep neat application code and get all of these handy for free.

The last example Christian talks about is how to build microservices. He thinks:

Building MicroServices with rest is an absolute fact. Build a service that uses rest endpoints to provide services and to use them for all interactions and integrations between services. Rest also has problems that are known to scale, such as tracking disruptive changes to services, understanding type safety between services, and the overhead associated with binary RPC-style services (at least HTTP 1.x). Today it is evolving into more elegant ways, such as non-blocking communication frameworks (i.e., Rxjava, vert.x), asynchronous communication patterns, and so on, even as RPC (such as GRPC) becomes more elegant.

Finally, the author believes that technology does not depend on specific technology stacks or tools, but if there is no effective technology stack and tools, good ideas can also be aborted. As Christian said, the continuous development of the micro-services sector, these new technology stacks and solutions can let some known issues resolved, and elegant to be resolved, he is excited, also deserves our attention. As more and more enterprises, communities, individuals involved, micro-services will be in more areas to take root and bear fruit.