Forwarded from: http://javatar.iteye.com/blog/1345073
Before large-scale service, applications may simply expose and reference remote services through tools such as RMI or Hessian, call them by configuring the URL address of the service, and perform load balancing through hardware such as F5.
(1) When there are more and more services, the management of service URL configuration becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing.
At this time, a service registry is needed to dynamically register and discover services, so that the location of the service is transparent.
And by obtaining the address list of service providers on the consumer side to achieve soft load balancing and failover, reduce the dependence on the F5 hardware load balancer, and also reduce part of the cost.
(2) With further development, the dependencies between services become complicated and misunderstood, and it is not even clear which application should be started before which application, and architects cannot fully describe the architectural relationship of the application.
At this time, it is necessary to automatically draw a dependency relationship diagram between applications to help architects clean up the relationship.
(3) Then, the call volume of the service is increasing, and the capacity problem of the service is exposed. How many machines does this service need? When should the machine be added?
In order to solve these problems, the first step is to count the current daily call volume and response time of the service as a reference indicator for capacity planning.
Secondly, it is necessary to dynamically adjust the weight. Online, increase the weight of a certain machine all the time, and record the change of the response time in the process of increasing, until the response time reaches the threshold, record the number of visits at this time, and then use This number of visits is multiplied by the number of machines to invert the total capacity.
(4) The scale continues to expand, and there is no longer a flat correspondence between applications, and starts to be layered, such as the core data layer, business integration layer, etc. Even if there is no circular dependency, it is not allowed to rely on the lower layer to the higher layer, so as to avoid subsequent Forcing circular dependencies.
At this time, it is necessary to define the architecture system in the registry, and list which layers are defined. When each service is exposed or referenced, it must declare which layer its application belongs to, so that the registry can discover the corruption of the architecture faster.
(5) With more services, communication costs have begun to rise. Who should be contacted if a service fails to be adjusted? What are the conventions for the parameters of the service?
At this time, it is necessary to register who is responsible for each service, and establish a service document library for easy retrieval.
(6) Slowly, some sensitive data are also serviced, and security issues have become important. Who can adjust the service? How to authorize?
Such a service may require a password, and you need to bring this password when accessing, but if you use a password, it will be very inconvenient to change the password, and all consumers must change it, so the dynamic generation of the token (Token) may be Even better, the provider will report the token to the registry, and the registry will decide whether to notify the consumer, so that a complex authorization model can be done on the registry page.
(7) Even if it is an insensitive service, it cannot be called arbitrarily. For example, a service suddenly has one more consumer, and the request volume of this consumer directly drags the service across, and other consumers fail along with it.
First of all, the service provider needs flow control. When the process exceeds the standard, it can refuse some requests and protect itself.
Secondly, the consumer agrees with the provider on the "Service Quality Level Agreement (SLA)" before going online. The SLA includes the consumer's commitment to call volume per day, the amount of requested data, the provider's commitment to response time, error rate, etc., and the SLA is recorded in the monitoring center. The timing is compared with the monitoring data, and the alarm will be issued if it exceeds the standard.
(8) Although there is an SLA agreement, if it cannot be controlled, it is just a gentleman's agreement. How to ensure service quality?
For example: an application is very important, and the other is not so important. They call the same service, and this service should be inclined to important applications, rather than treated equally. When it cannot be supported, the access of unimportant applications should be restricted to ensure the availability of important applications. , how to do this. At this time, service routing is required to control different applications to access different machines, for example:
application separation:
consumer.application = foo => provider.host = 1,2,3
consumer.application != foo => provider.host = 5,6 read-
write separation:
method.name = find*,get* => provider.host = 1,2,3
method.name != find*,get* = > provider.host = 5,6
(9) After the service is online, it is necessary to verify whether the service is available. However, due to the restriction of the firewall, offline access to the online service cannot be performed. You have to write a test Main first, and then put it online. It is very troublesome to go up and execute, and it is easy to forget to verify.
Therefore, there needs to be an automatically running verification program on the line. The user only needs to fill in the service method to be verified on the interface, as well as the parameter value and the expected return value. When a service provider goes online, the use case will be automatically run. And send an email to notify the person in charge of the running result.
(10) There is a difference between a service application and a web application. It is a background Daemon program and does not require a web container such as Tomcat. However, because the company was mainly based on web applications before, and the specifications were all based on web applications, it had to run the service in a web container that was not used at all, and it was very troublesome to build such a web project.
Therefore, it is necessary to implement a non-Web container. Simply load the Spring configuration in Main, and provide a Maven template project. Just mvn dubbo:generate can create a complete service application.
(11) There are more and more people developing services, and they pay more attention to development efficiency. IDE integration support is essential.
Through the plug-in, the service can be run directly in Eclipse, the provider can directly fill in the test data test service, and the consumer can directly mock the service without relying on the provider to develop.
(12) Because the exposed service is very simple, the online service is becoming more and more random. Sometimes the architect responsible for the service does not know that someone has launched a service, which makes the online services mixed, and even duplicate services appear, while the service is offline. Going online is more difficult than going online.
A new service online approval process is required, which must be approved by the service-oriented architect before it can be launched.
When the service is offline, it should be marked as outdated first, and then notify the caller to modify the call as soon as possible, until no one calls the service before it can be offline.
(13) Since the experience of service interface design has been slowly accumulating, many interfaces cannot be achieved overnight. In the process of modification, how to ensure compatibility and how to judge whether it is compatible? Also, on a deeper level, are the business behaviors compatible?
According to the type of protocol used, it is possible to analyze whether the changes of the interface and the domain model are compatible, such as: comparing the addition and subtraction fields, method signatures, etc.
For business, it may be necessary to form a Technology Compatibility Kit (TCK) based on automatic regression test cases to ensure compatible upgrades.
(14) With the continuous upgrade of services, some unexpected things always happen, such as memory overflow caused by cache write error, failure is unavoidable, every time the core service hangs, affecting a large area, people panic, how to control the failure influence? Can the service be functionally downgraded? Or resource degradation?
Declare the strength of dependencies between applications, which functions are strongly dependent and which are weakly dependent, and then calculate the impact surface based on the strength of the dependency, and periodically test and review it to enhance the optimization and fault tolerance of services on the critical path, and clean up services that should not be on the critical path. .
Provide fault-tolerant mock data. Mock data should also be dynamically distributed in the registry at runtime. When a service is unavailable, use mock data instead to reduce the occurrence of faults. For example, for a verification service, when all verification services are suspended After that, return false directly to indicate that there is no permission, and print the Error log alarm.
In addition, the front-end page should also be downgraded by Portal. When the Portal cannot obtain data, it can be directly hidden or replaced with other modules for display, and a function switch is provided to manually intervene whether to display it, or to limit how much traffic can be displayed.
(15) When there are many small services, it may be necessary to combine large services of multiple small services. For this reason, an intermediate layer has to be added to expose a new service, and other small services can be adjusted in it. Such a new service business logic Less, but brings a lot of development work.
At this point, a service orchestration engine is needed, with a built-in simple process engine, just use XML or DSL to declare how to aggregate services, and the registry can directly deliver the aggregation logic to consumers, or deploy a general orchestration server, all requests are orchestrated Server forwarding.
(16) Not all services have a large amount of access, and many services have only a small amount of access, but it is necessary to deploy two machines that provide services to perform HA mutual backup, how to reduce wasteful machines.
At this time, it may be necessary to allow the service container to support the deployment of multiple applications on one machine, which can be isolated by multiple JVMs or isolated by ClassLoader.
(17) If multiple applications are not developed by a team and deployed on one machine, it is very likely to misuse and stop other people's services.
Therefore, it is necessary to realize automatic deployment, and all deployments do not require manual intervention, preferably one-click deployment.
(18) How to improve the utilization rate of the machine when the machine is always idle and busy, or redundant machines are used for disaster prevention?
Now that it can be deployed automatically, based on the monitoring data, resource scheduling can be achieved, and machines can be automatically added and deployed according to the pressure of the application.
If your application is international, there are Chinese stations, American stations, etc., because of the time difference, when the machines in the American station are idle at night, it may be the busy time of the day in the Chinese station, you can automatically allocate and Deploy both applications.
Summarized by keywords:
1. Service registration and discovery
2. Soft load balancing and fault tolerance
3. Service monitoring and statistics
4. Service capacity assessment
5. Service online approval6
. Service offline notification
7. Service leader
8. Service documentation
9. Service routing
10. Service orchestration
11. Service black and white list
12. Service permission control
13. Service dependencies
14. Service Hierarchy
15. Service Call Chain Tracking
16. Fault Conduction Analysis
17. Service Degradation
18. Service Level Agreement
19. Service Automatic Testing
20. Service Masquerade Fault Tolerance
21. Service Compatibility Detection
22. Service Usage Report
23. Service Weight Dynamic Adjustment
24. Service Load Balancing Adjustment
25. Service Mapping
26. Service Template Project
27. Service Development IDE
28. Service Health Detection
29. Service Container
30. Service Automatic Deployment
31. Service Resource Scheduling
Forwarded from: http://javatar.iteye.com/blog/1345073