The author is a graduate of June 19, leaving just experienced recently, quit, nothing else during the home office, roll up your own company for some insight into the micro-services and springcloud novice white, have said the wrong place to look forward great God correction.
What micro service?
In about something new at the same time, you may wish to look at the background it appears, and it appears to solve any problems.
In the Java web application development process, a more typical architectural style is to the front (Front-end) and back-end (Back-end) all files under all on the same project, or through a maven build tools such as playing gradle war package into, or thrown into the jetty tomcat services run up the container. Similar to the following:
A disadvantage of this architecture is that:
1 complex and simple. I first company used is SSH architecture (Spring + Struts + hibernate), typical javaweb application was not useful to manage project dependencies maven, in the development of which often need to manually change a line of code to fight war and then thrown into the server tomcat, the search process kill process, restart tomcat. So all of our project team have a group, as long as who should say something to restart, other groups often intern bug in the test, we will develop a local connection timeout, and this time you can go out and smoke, haha.
2. Do not conducive to expand and update technology. This is easy to understand, only a project structure, the back-end using java, it can only be java language, only with php php, once the day to reconstruction projects, Naogua Zi can give you dry rot.
3. difficult to maintain and understand. Just imagine, when graduating students into the company, a project more than a dozen back-end modules, each dozens of packages, when debugging break point you may forget why you want to debug the breakpoint.
After a monomer hell, the industry will be looking for a better solution, micro-services (MicroService) came into being -
the micro-service architecture can be said is how to break down into a series of features an architectural pattern services. Divided into more than a simple understanding is, for example, you had a blog system can be split into customer service, community service, integration services, etc., each service can be a single application that can run within a particular container, to achieve decoupling applications.
FIG above is a simple sketch I painted micro services, the original divided into multiple monomer applications and services according to the service, each service is equivalent to a web application, the information interaction between them through a network protocol, it will not often changed a service a, C development at the time to wait for the entire project a restart this dilemma.
Micro-services division generally based on business requirements, there is a concept of service granularity. Size should not be too thick and too small, if you are a simple user interface to simply log in to dao and service split into two services, which is actually not necessary, but magnified the complexity of the overall project; opposite a huge electricity supplier system you only into the warehouse service and order services, but there may be integral, mail, etc. in order not small module which, this coupling is still quite high.
What is SpringCloud?
Springcloud Pivotal team is introduced based on the above basis Netflix OSS to build micro-services architecture program.
First, SpringCloud not a frame-to-use out of the box, this time in a lot of beginners often confuse this concept. You can be understood as, SpringCloud is a thought, a method, a complete set of micro-services architecture concept or a family bucket (similar to KFC ha ha), which will mature industry a variety of micro-services architecture components to make an integrated, for example, service management, service gateway, service fuse, unified configuration, component communication service, link tracking, service monitoring, and so a sophisticated micro-service architecture needed, springcloud place them in their own bucket, and not to repeat create the wheel .
Turning to micro-services, we have to mention it a few core concepts:
1. Service Management
When a problem we started building micro-services architecture when first encountered is: as consumers how to access and call service provided by the service provider; as a service provider how to make services they offer so that other consumers transfer. In traditional application of which we are directly in the development of the language level to solve this problem, for example, Class A -> call -> B class methods, even if it is a multi-module project, may only be used for remote call Http client tools, assuming that a serving has 100 instances were deployed on 100 machines, then you are using a storage array in the code examples that 100 Random address and use it to achieve service invocation, it may not have to wait until tomorrow, you now this approach would be ashamed of yourself. In the micro-service architecture, each service may be multiple instances, and these examples off the assembly line in non-stop on-line, how they know each other? Physical address is certainly not desirable, because you do not know tomorrow you will not be because of the huge traffic and bought a few servers deployed service (do not ask, ask that the money). If a service is not online, then when you call the network will be a long wait, eventually leading to failure.
Service management is put forward to solve the above problems. Through service found that consumers do not need to know the physical address of the provider, you can just call the service realized by implementing well-defined service name; providers do not care about their service will eventually call by whom. Service registration mechanism is to allow the service provider at the time of registration on-line information service offered to speak to a service management server, and notifies management server offline at the time of their information deleted instance, avoid traffic entering the wrong address.
2. Micro service load balancing
for load balancing can be understood by the figure. Traditional applications may implement load balancing load balancing device (the Nginx) requested by the user at the inlet. But in the micro-service architecture, this approach is not feasible, because the user not only to consider the request, but also need to consider the call load between the service, but at this time if we continue this way, it will certainly increase the system the complexity of the structure, and you can not expect your examples of how the service will change. Therefore, for the micro-service call load balancing needs to find another way. Therefore, the industry proposed the client load balancing idea that there are other instances save a list of all the services of a management server in the service consumer client, when traffic comes in, the client to achieve according to their own policies.
3. unified entrance micro services
First of all, the service is more micro, enterprise applications which, if the choice of micro-service architecture, can not be just one or two instances, such as A service may have dozens of instances, there are hundreds of thousands throughout the service, then the question , you are back-end engineer, you may just serve you in charge of a few relatively clear, but have not thought about the psychological shadow of the tip of MM? (PS. yeah mom, I want to remember that it addresses multiple services. ...) this time of friendship may turn to turn the boat said. As a front-end or a third party, this is definitely one you do not want so many micro-services deal, this time on the need to provide a unified entry micro services to help clients routed to the service needs based routing rules laid down in advance.
4. fault-tolerant micro-services.
Fault-tolerant, in fact, another way is also called fuse. Imagine, if there is no system in which the circuit fuse, then the temperature is too high at the circuit lines directly burn up, this is a very terrible thing, is the same in which micro-services architecture. Micro-service architecture from the early building destined to be highly decentralized, distributed architecture, service calls between the network spread out, is likely to call a service involving a number of downstream services. Among electricity supplier system, assuming that there are 100 single-user requests, equivalent to 100 threads started the next single orders related to the service, you need to inform warehousing services after deduction of the corresponding stock at a single integration services, warehousing services, order services, after notification and integration services increase the user points, assuming that when you call integration services, network integration services due to the reason for the crash or down, so in the absence of a blown case the user may only see the interface has been going round in circles, until the visit timeout out of a 500 error, what the hell, a pile of letters. If the user is under enormous amount, all the threads are stuck in integration services here until the system crashes, memory overflow and so on, causing the industry's more classic "services avalanche" phenomenon.
With the service fuse, this time we can specify a timeout rule for integration services, after detecting the timeout and retry invalid, we can define their own good in advance a relatively friendly response, or it may persist a record in the database, until after the recovery network data can be manually modified. Yes, fault tolerance is doing this thing.
5. Micro unified configuration services
In the single application which, the project may be multiple configuration files, you can modify and unified management under the same item. But in the micro-service architecture which, due to the multi-service number, and there may be the same configuration data, etc., at this time if or distributed separately managed in each service, then the face of hundreds of service instances when this management the difficulty is undoubtedly very large, you can preview the file you want to change the configuration of a huge difficulty. And we do not want to change the configuration of each system each file, so there is likely to cause great change and confusion services.
6. The micro-monitoring services.
Flexible and powerful micro services is a double edged sword, bringing dawn for developers but also brings with it "a nightmare." General debug and trace analysis in a single application is not a problem, because it is a concept of zero as a whole, everything under one project. Calls for the importance of tracking and analyzing believe I do not say we all know, especially when it is time to apply formally launched, there is a good log analysis can quickly locate the problem. However, in micro-services scenario it is difficult, because of the above mentioned call micro services that may exist between multiple services downstream of service, and each service has its own logging, then, how all log consolidation into a unified log system, this will be a very big challenge. Of course, springcloud in this micro-monitoring service provides log aggregation, visualization log analysis, call link tracking solutions, etc., etc. are now more ELK designed for system log born technology stack, it can be thought to build a powerful micro-services monitoring system provides a powerful help.
Having said that, in fact, I just want to learn springcloud and micro-service children's shoes were told their shallow understanding, bearing in mind, start learning a language must understand its core idea and a variety of scenarios, any mature frameworks to solve a variety of business problems and birth, and it is micro-services architecture springcloud a good solution. A little tired, the first blog a bit shabby, if you have any questions I hope you correct, start from the back will continue to build and update the relevant Springcloud of combat.
Last but not least,talk is cheap,show me the code
