The article is moderate in content and is recommended to be read in 7 minutes.
If you are unfamiliar with any of the concepts mentioned in the article, it is recommended that you read it in 12 minutes and take a look at the references I have attached at the end of the article.
This article is purely personal original, reproduced please indicate the source.
Before we embark on our journey, please allow me to review with you one more sentence:
This applies to any lofty concept: SOA, DevOps, DDD, Agile, Cloud, etc., including the “microservices” I want to talk about right now.
Why is that?
There are too many “experts”. As the saying goes, “There are a thousand Hamlets in a thousand experts’ eyes”.
When you hear a lot of concepts, you think you’re well-informed, and then you end up wondering, “Oh my God, who am I supposed to believe?”
In accordance with the old man see: letter who are better than their own letter!
Such a complex concept, is really elusive, but have to go to understand, after all, the circle of the Internet has too many beasts of prey, a little slack, will be photographed on the beach.
In fact, the realization that I was in such a dangerous situation was a kind of hindsight. Maybe I had known it long ago, but I didn’t act on it. It is only now that I am acutely aware of the deep malice of this age towards us ordinary people.
Yeah, I had to struggle, leave a mark on my future self.
Throughout my short experience, I can sum up six words of wisdom:
I’ve heard of it. I haven’t
IT will be a microcosm of how techies in the IT world struggle with the breadth and depth of their knowledge.
What a painful realization, no! ~ ~
My life is full of experience, but very short of refinement and refinement. Although I have tried to be “melocritical” on social media a few times before, those are the feelings of life growth, and there are still few of my professional and technical aspects.
So, in order to avoid getting lost in the current wave of the Internet, I decided to take a look at what I’ve learned. I happen to have some recent hands-on experience with microservices, and what I know about them.
1. ALL in ONE
Before I talk about micro-services, I like to talk about a development model that has plagued me for three years: ALL in ONE.
Some might call it a “monolithic application.”
The word “torture” was used, and the hatred was palpable.
In fact, this feeling was not at the beginning, but AFTER a period of time in the micro-service community, I discovered:
How the fuck did I ever get through this?!
The ALL In ONE development model is probably the first stage of my generation’s understanding of the software development process.
Open Eclipse, create a Dynamic Web Project, put Java code in SRC, JSP in WebContent, and jar package in WEB-INF/lib.
Later, with maven, a project divided into multiple modules looks much cleaner, and jar packages are suddenly much less. It is much faster to Checkout a project from SVN, and it is much more convenient to compile and package.
At the beginning, I was proud of the Linux command, to the server installation JDK, Tomcat, MySQL, what are all handy.
Once I had skillfully typed out the WAR package and put it in the Webapps directory, the deployment was complete.
Even so, this development model is relatively “stable” :
From a developer’s perspective, it’s not too expensive to learn at least technically about a project, unless you’re unlucky enough to have a pushy colleague. Second, each deployment has become surprisingly easy, with few of the problems that DevOps now faces.
From a coding standpoint, all dependencies are centralized in a single project, and there is no need for remote calls.
Finally, my boss asks me for a diagram of the system architecture.
Since it is a single application, it is not a dime with the cluster, of course, want to transform into a cluster is not impossible.
With such a thin system architecture, it is hard to believe that it can withstand much traffic, performance is commendable.
In terms of code structure, at the end of the day, it will be embarrassing to find that the coupling between functional modules is getting higher and higher, just as the so-called “cutting constantly, but also disorderly”. In the end, it will be very desperate to ask yourself: should I refactor?
If you want to write a unit test and run a Case, you have to restart the project for 5 minutes.
For small sites with fast delivery goals, an ALL in ONE development model is a good idea.
2. Service-oriented Architecture (SOA)
After a long hesitation, want to introduce SOA in passing? To be honest, it is not the limit of space, but the limit of knowledge. With my current knowledge of SOA and microservices, it seems like a struggle to distinguish between SOA and microservices, but I’m trying to understand. What if one of these moments my pulse clicks?
Another reason, if you think about it, when we talk about microservices, what are we talking about? SOA is probably an unbridgeable chasm!
SOA is definitely the big brother in terms of qualifications, having been proposed by Gartner in 1996 and slowly gaining popularity in 2000. So when we talk about the “up-and-comer” of microservices, we tend to give SOA an adjective: “traditional”.
SOA can be thought of as an architectural style or even a design pattern. Literally, when we design a system, we design a service as a component.
So what is a Service? A service is an abstraction of a set of actions (business activities).
SOA advocates coarse-grained, so there is a need for discretion when dividing services. One of the biggest benefits of coarse-granularity is that there are not too many service interfaces to provide externally, reducing the performance cost of repeated calls between services. However, there is also a need to consider the reusability of services, and it is not a good thing to partition services too simply and rudely. In between, you need to find an appropriate balance point based on the actual business scenario.
When we put the order, payment, account, such as abstract into small modules, this process we can be seen as doing service to extract, but not to do so you can complete a service oriented architecture, the real value of SOA is to integrate all of the service, make them relatively independent and can work together in an orderly way, through a series of business operations.
Therefore, I see SOA as having two core elements: services and governance.
So how do several services communicate with each other?
This seems to be a very deep dive, covering several concepts in the SOA space, and I’m trying to explain them.
Of these, the most famous are SCA and ESB.
Service Component Architecture (SCA) is a specification for SOA implementation. This specification is approved by IBM, Oracle, SAP, BEA and other big manufacturers, so it is also widely spread among the people.
SCA determines how SOA is implemented from a programming model, independent of any specific technology. You can build units of functionality or components in different programming languages and then expose them as services via SOAP, JMS, RMI, REST, or other protocols.
The basic building block of SCA is Component, which can be thought of as a collection of implementations for a set of interfaces, or as an existing external system. SCA aims to free developers from the complexity of the underlying protocol processing, shielding them from all technical details and focusing on the implementation of business functions. A well-known framework based on SCA is Apache Tuscany, which is beyond the scope of this article. Attach a typical SCA architecture diagram to get a feel for it:
Compared with JBI (Java Business Integration) proposed by SUN, JBI is not so lucky, especially after The acquisition of SUN, JBI has fallen into the dilemma of existence in name only, and its prospects are naturally not optimistic.
JBI was originally positioned as an extension to existing Java EE containers and was not intended to be compatible with components from other platforms. The result constructed based on JBI specification is essentially a running container, which has a message distribution engine and a protocol conversion engine, so it supports more protocols, integrating HTTP, RMS and JMI.
This is well worth pursuing for the JAVA ecosystem as a whole, but it is hard to reuse for the current SOA architecture because it is too stretched.
In general, SCA has become the de facto standard for SOA, and SCA is almost always involved when SOA is mentioned.
Enterprise Service Bus (ESB) is commonly translated as Enterprise Service Bus in the industry. I tried baidu “ESB”, the first few are enterprises to do advertising, roughly is to provide ESB services for enterprises, and Baidu SCA will not have any advertising. This in a sense justifies my vision that the ESB is a concrete implementation based on the SCA specification.
Since it is the bus of enterprise services, the traffic it carries is enormous, and a wide variety of services are connected to the bus in different ways, so the ESB needs to support and adapt different protocols first, and then integrate, orchestrate, and monitor each service. The emergence of ESB can effectively break the situation of “information island” inside the enterprise, so that data can also become the “working capital” of the enterprise.
If you have read this far, it is not difficult to understand the two core elements of SOA I mentioned above: services and governance.
3. Talk about microservices
At the end, the most important finale has finally appeared!
I can’t help but take Martin out and worship him twice.
Agile is born with a sweet smile from Martin on earth; Stroke your beard. Microservice is going crazy.
Going back to ALL in ONE, applications developed under this model are poorly scalable and maintainable, which goes against the philosophy of microservices.
The purpose of microservices is to effectively split applications and achieve agile development and rapid deployment.
Above this small square, in the Internet circle, by many giants who are talking with relish.
This is a three-dimensional model, with three directions representing three scalable dimensions:
X-axis: Horizontal scaling at the Application level. Of course, they’re all hiding behind Load Balance, waiting to be tapped;
Y-axis: can be regarded as in-application extension, that is, each service in an application can deploy multiple instances;
Z-axis: Similar to X-axis, both are application-level extensions, except that each copy only accesses part of the data, i.e., there is more work of “repository and table”.
Although the three dimensions are perpendicular to each other, it does not mean that there is no relationship, nor does it have to choose one of the three.
We can try to feel it:
X-axis means to run multiple application instances and Load Balance, which improves the overall pressure resistance of the application.
Y-axis means to further decompose the application into micro-services and deploy multiple instances, which means to improve the performance of certain services within the application and make them less likely to encounter bottlenecks.
You can also use Z-Axis to partition services by data (sub-table) when there is a large amount of data.
From this perspective, these are several ways to improve application performance.
Back to microservices. Here is a summary quote:
As Martin himself said, everyone can be different about microservices, but there are some general standards.
1. System composed of distributed services
2. Organize by business, not technology
3. Make living products, not projects
4. Smart Endpoints and dumb Pipes
5. Automated Operations (DevOps)
6, fault tolerance,
7. Rapid evolution
In my opinion, the idea of microservices is actually a kind of inheritance and extension of SOA. Microservices absorb all the advantages of SOA and also have the functions that SOA does not have.
The first three criteria are also applicable to SOA, while the latter are different.
The fourth standard strikes at the heart of the ESB concept mentioned earlier. SOA focuses on the governance of services, and the governance of services naturally becomes the dominant side of the system, centered on the ESB, which becomes heavier and heavier as more services are connected. So microservices advocate de-ESB, decentralization, message parsing within services.
There is not much emphasis on 5-7 standards in SOA because they are no longer within the scope of their standards. In microservices, it’s a must.
It is not difficult to see that micro services fully have the distinctive characteristics of this era, which are not available in the past, because they are not so valued by people.
At present, with the support of Docker, DevOps and other key technologies, the whole micro-service ecosystem is relatively complete, and it is not difficult to understand why micro-service is so popular.
On the governance of micro services, I will not repeat this, and intend to start a new chapter.
conclusion
This article, from ALL in ONE to Microservice, is a transformation of my development model over the years. There may be new concepts to come, but I always warn myself not to get lost in the tide.
I hope it helps.
THANKS!
The attached:
References:
1. SOA standard —-SCA architecture idea
2. SCA Topic — from IBM
That Microservice thing
4, Microservices: Decomposture Applications for Deployability and Scalability