preface

Hello everyone, MY name is Ao Xiaojian. Today, the topic I would like to share with you is “Using open source Community to build micro-service ecosystem”.



The main contents are as follows:

The content is divided into three major sections:


1. Core technology of microservices

2. Currently available open source microservices framework

3. Infrastructure that supports microservices


It should be noted that due to limited time, the amount of content shared is too much, so:


1. The content is just a list, not a specific introduction

2. The scope of personal knowledge is limited, so it is inevitable that there are some omissions in the enumeration process

3. I will give some personal suggestions for some scenarios, but please note that these are my own suggestions for your reference only

Here’s a list of what we’re going to talk about today, and it’s quite a starry list.



Part ONE: Core technology


Now for the first part: core technology.

The main content is the first row of four techniques:


– Interprocess communication

– Service registration and discovery

– Load Balancing

– fusing


The three items in the second row are generally included in libraries or frameworks and are not usually presented separately, so we won’t expand them in detail.

Before we start talking about interprocess communication, let me point out one more concept that is extremely important for microservices:


In the microservices architecture, in order to completely isolate different services, the most resolute solution is to force services to communicate with each other: ** remote access **


In this regard, microservices stand in stark contrast to Java modular solutions represented by OSGi and Jigsaw.

There are many ways of interprocess communication, whose diversity is reflected in two aspects:


– There are three styles of solution: REST, RPC and customization

– The interaction mode has two dimensions: one-to-one and one-to-many based on the number of interaction objects, and synchronous and asynchronous based on the response mode.

The possibility of the combination of the two dimensions is shown below:

Common network libraries in the industry at present:

Since Netty is usually the most popular choice, let’s expand on netty version selection.


It is important to note that The ForkJoinPool 5.* version has been officially abandoned by Netty because it introduced too much complexity without any clear performance improvements. If you are using Netty 5.* Alpha, please revert to version 4.0 or 4.1.

Rest research is limited to a few simple recommendations.

There are about a dozen RPC frameworks in the industry. Here, only three are introduced in detail, representing the old and new generations of RPC frameworks respectively.

Here are some personal tips:

One caveat: if you need mobile support and want to use HTTTP 2’s new features, you’ll have to choose gRPC.


Talk about the third route: customization. There are many students who choose this plan.

There are also many options for message queues, and here are three common ones with a special case, NSQ.

The implementation of service registration and service discovery can be divided into two schools according to different requirements for consistency:


1. Strong consistency

The common distributed consistency protocols are PAXOS and Raft. Raft protocol is easier to understand and implement than PAXOS, so the most recent distributed consistency solutions are Raft protocol.

Zookeeper uses the PAXOS protocol (actually an improved version of ZAP) while Raft is on consul and ETCD.

2. Weak consistency

If consistency is not high, you can choose a DNs-based solution, or you can choose a Redis based solution like Sina Weibo’s Vintage.

Common strong consistency schemes are as follows:

Weak consistency schemes are rare, and are usually used in simple scenarios such as REST or HTTP + JSON/Web Service.

When selecting a load balancing solution, distinguish between server load balancing and client load balancing.

There is only one open source solution available for fuse. Some students complained that Hystrix’s design and implementation were not good, but it improved a lot in 2016.

Part two: Microservices framework

Dubbo is always an indelible name in the domestic discussion of SOA, servitization and microservices. Personally, Dubbo is “the most comprehensive SOA framework in The country”, and basically has all the functions that an SOA framework should have.

Here’s a look at dubbo’s glorious history:

Comparing the current situation, it is amazing:

Dubbo’s rise and rise is seen on a timeline like a shooting star across the sky.

Dubbo’s summary, there are more personal emotions in, only for reference.

Motan, can you take over dubbo’s mantle?

Every servitization framework is asked: Why don’t you just use Dubbo? Motan is not immune 🙂

Add: This is one of the reasons why I chose to design the dolphin microservices framework instead of Dubbo. The cost of retrofitting is much more than a neat “tweak”.

Motan’s technology stack:

Here is the OSS suite, a heavyweight open source product from Netflix.

One of the interesting ways of Netflix is that its components are divided in detail. Each independent function is divided into separate components, which is convenient to choose as needed. Like one.

Some personal views on OSS belong to the nature of the bone in the egg, just for reference.

Let’s start with a series of works by another industry heavyweight, spring, which all Java students are most familiar with.

Before we look at Spring’s support for microservices, let’s take a look at spring’s journey over the past fourteen years:

Start the uncle style nostalgia session, remember when we read these books, we were so young 🙂


A few things to say: Uncle Rod Johnson is one of the industry titans I most admire and admire. If you can do what he does, you’ll have no regrets.

Since its debut in 2002, Spring has produced many milestone releases and added many heavyweight features. However, in my opinion, the launch of Spring Boot in 2014 is the biggest change and rethinking of Spring in the last three to five years.


The emergence of Springboot is a sign that Spring is no longer obsessed with snake, but is starting to rethink itself and reinvent itself, which is far more important than adding a new feature or two to a framework that has been around for more than a decade.

To summarize, this is why I chose Spring Boot as the cornerstone of the new Dolphin microservices framework.

Spring Cloud, a newcomer from 2015.

Embodies spring’s expectations and aspirations for the microservices architecture space.

There are a large number of sub-projects. Here are just a few that are commonly used:

The emergence of Spring Cloud’s Netflix sub-project is more like Spring’s previous style of doing what it does best: integration.

The following content is added at the back, not directly said in the venue, pure personal vomit bad:

Personal assessment of Spring Cloud: Good idea, right starting point, right time to enter market vacancy. However, the actual performance of Spring Cloud has always given the impression that one’s hands are tied and one’s feet are tied. Compared with the performance of Rod Johnson more than ten years ago when he was full of spirit and grandeur and overturned the THRONE of EJB with laughter, Spring Cloud today is not capable, confident and has a too small pattern to become a big success. Look forward to a change.

Here are my thoughts on the current microservices framework:

Part THREE: Infrastructure

Since the lecture is only one hour long, there are many aspects of infrastructure that cannot be listed, but this time only a small part of them will be introduced.

Distributed configuration management is the current mainstream of the underlying storage scheme, if you build your own options are nothing more than the following:

You can also choose an existing open source product:

There are many options in the APM space, but not many open source options:

ELK is king in log analysis, but there are new players:

conclusion

I’ve listed dozens of names, but I don’t want you to explore every one of them. If you need to make technical decisions in daily life, I have two things to say:



  1. Look up at the stars: broaden your horizons, broaden your knowledge, even if it’s just being proficient in names, at least know that there’s a good thing somewhere, that there’s an alternative in a field

  2. Based on the present, I only take one scoop: eventually will fall to the ground, can play turn things are good things. In addition, although there are many good things, it is good to find one that can suit yourself and solve the problem. Don’t be greedy, don’t be greedy


Distributor profile:

Ao Xiaojian, senior architect of PPmoney, 14 years of software development experience, in-depth research on agile development and architecture design, once worked in Asiainfo, Ericsson, ViPSHOP. Currently, he is the head of INFRASTRUCTURE at PPMoney, responsible for the development of Dolphin microservices architecture and supporting infrastructure, and promoting the company’s full service.

This article is reprinted from the wechat official account freshmanTechnology