That's a lot of time.
That day in June, the weather is cooler than ever, my daughter-in-law, while clearing the table, said to me absently: you don't seem to have been reading much lately. I was brushing up on the news, as if I had been hit by a loud thunderbolt from the sky, and I was at a loss for words. Yes, in recent months, all things come together, coupled with two major projects come one after another, there is indeed a little bad, so always in the free time to soak in the news to chat to relieve the worry, and then look back, vaguely some of the feeling of a world apart. So clean up the mood, turn over the bookshelf lying in a long time neat three steps. Perhaps too long without reading, a breath, Uncle Bob Clean series of three books are read, focusing on recommended Clear Architecture, part of the chapter is recommended to repeat reading, such as Part 5 - Software Architecture, which allows you to have a real enhancement to the code, the programming, the software will have a different understanding.
Clean Code is the next best thing, basically writing some common statutes, most of which are also well known, and the data structure and object oriented view is one of the few things that made me go wow, so if you're really trekking down the code road, a quick flip through will suffice.
The Clean Coder is probably the least useful for individuals. It's true that writing about people is the hardest, it's impossible to focus. There's a lot of talk, but none of it feels in-depth, or that the author is writing about himself, and it's hard to map it to himself. Of course, Chapter 2, Say No, with Chapter 14, Mentoring, Apprenticeship and Craft, is still worth reading.
In addition to reading technical books, I opened Mr. Zhu Shenghao's translation of Shakespeare with fear and trepidation, and I couldn't stop reading it. Its magnificent resignation and humorous metaphors really make people can not help but read aloud.
。。。
Then again, with over 120 hours of ebook reading from June to now, the average turned out to be over an hour of free time per day, which is just beyond belief.
After reading the book Neat Architecture, I wanted to write code, hence this post.
Soul Torture - What to do about downtime
In order to solve the problem of a large number of rule configurations in the system, a visual expression engine, RuleLink, was built together with colleagues.RuleLinK, a non-totally self-developed visualization and expression engine.The solution solves almost all configuration problems within the company. Especially important point , all the configuration of the business students can be self-service completion . With the depth of the business and add some custom functions , increase the formula and calculation functions , add components seamlessly embedded in other business ... I once thought that the current features can already meet most of the scenarios. Really to Wsin strong students said: industry financial projects aredeep dependenceRuleLink's, flow marking, associated subjects. I know he looked at the data and 10 points RuleLink executed 50,000+ times. This also means that if RuleLink is down, the business financial services are also down, which means a huge accident. This is a problem, the company's business is indeed very low-frequency, but not so much financial data. If we can make RuleLink more stable has become the primary problem at present.
High Availability vs. Fewer Dependencies
To improve the availability of a service, increasing the instances of the service is the fastest way. But considering our own business attributes, and the fact that the karma is only invoked in short bursts of high frequency at a few fixed points in time each day. Adding nodes doesn't seem to be the most economical way. Look at Uncle Bob's Clear Architecture book, there is such a formula for the stability of the architecture: instability, I=Fan-out/(Fan-in+Fan-out)
Fan-in: inward dependency, this metric refers to the number of component outer classes that depend on component inner classes.
Fan-out: outward dependency, this metric refers to the number of component inner classes that depend on component outer classes.
This idea applies to the stability of each microservice at the same time, one less external dependency, stability increases a little. Standing in the industry financial system , if I can reduce the number of invocations , its stability is improving , bulk interfaces can reduce dependencies to some extent , but did not solve the fundamental problem . Then reduce the number of calls to the limit will be what? The answer is:Once.If the rules stay the same, I just load the remote rules on startup and perform parsing of the rules in the local container. If there is a change, we just need to listen for the change. This greatly reduces the dependency on RuleLink and eliminates the need to add RuleLink nodes. In fact, most configuration centers are designed this way, such as apollo, nacos. Of course, the implementation of this paper also has a lot of borrowed (copy) apollo's ideas and implementation.
Server-side design
The model is relatively simple, the application subscribes to the scene, and when the scene and its rules change, or when the subscription relationship changes, it generates a record of the application and scene changes. Similar to the generator-consumer are modeled using DB for storage.
The "push" principle
The overall logic refers to the apollo implementation. After the server is started, create the bean ReleaseMessageScanner and inject the change listener NotificationController.
ReleaseMessageScanner A thread that scans for code changes on a regular basis and notifies all listeners if there are changes.
How does NotificationController notify the client when it learns that a configuration has been published?
The realization is as follows:
1, the client will initiate an Http request to RuleLink's interface, NotificationController
2, NotificationController will not return the result immediately, but through the Spring DeferredResult to hang the request
3, if no configuration of interest to the client is published within 60 seconds, then the Http status code 304 will be returned to the client
4, if there is a configuration release that this client cares about, NotificationController will call the setResult method of DeferredResult, passing in the list of changed scenarios, and at the same time the request will be returned immediately. After the client gets the changed scenes from the returned result, it will directly update the scenes in the cache and update the refresh time.
The ReleaseMessageScanner is relatively simple, as follows. the NotificationController code is also simple, that is, it receives an update message, and setsResult to return it (if there is a request waiting).
public class ReleaseMessageScanner implements InitializingBean { private static final Logger logger = (ReleaseMessageScanner.class); private final AppSceneChangeLogRepository changeLogRepository; private int databaseScanInterval; private final List<ReleaseMessageListener> listeners; private final ScheduledExecutorService executorService; public ReleaseMessageScanner(final AppSceneChangeLogRepository changeLogRepository) { this.changeLogRepository = changeLogRepository; databaseScanInterval = 5000; listeners = (); executorService = (1, RuleThreadFactory .create("ReleaseMessageScanner", true)); } @Override public void afterPropertiesSet() throws Exception { (() -> { try { scanMessages(); } catch (Throwable ex) { ("Scan and send message failed", ex); } finally { } }, databaseScanInterval, databaseScanInterval, ); } /** * add message listeners for release message * @param listener */ public void addMessageListener(ReleaseMessageListener listener) { if (!(listener)) { (listener); } } /** * Scan messages, continue scanning until there is no more messages */ private void scanMessages() { boolean hasMoreMessages = true; while (hasMoreMessages && !().isInterrupted()) { hasMoreMessages = scanAndSendMessages(); } } /** * scan messages and send * * @return whether there are more messages */ private boolean scanAndSendMessages() { //current batch is 500 List<AppSceneChangeLogEntity> releaseMessages = (); if ((releaseMessages)) { return false; } fireMessageScanned(releaseMessages); return false; } /** * Notify listeners with messages loaded * @param messages */ private void fireMessageScanned(Iterable<AppSceneChangeLogEntity> messages) { for (AppSceneChangeLogEntity message : messages) { for (ReleaseMessageListener listener : listeners) { try { ((), ""); } catch (Throwable ex) { ("Failed to invoke message listener {}", (), ex); } } } } }
Client Design
The above figure briefly describes the principle of the client implementation:
- The client and server maintain a long connection so that configuration updates can be pushed out first. (Implemented via Http Long Polling)
- The client will also pull the latest configuration for the application from the RuleLink Configuration Center server at regular intervals.
- This is a fallback mechanism to prevent the push mechanism from failing and causing the configuration not to be updated
- Client-side timed pulls will report the local version, so in general, for timed pull operations, the server side will return 304 - Not Modified
- The timing frequency is pulled every 5 minutes by default, and can also be overridden by the client by specifying the configuration item: in minutes at runtime.
- After the client gets the latest configuration of the application from the RuleLink Configuration Center server, it writes to memory and saves it to the SceneHolder.
- You can use RuleLinkMonitor to see when the client configuration is refreshed, and whether the rules in memory are the same at the remote end.
Client Engineering
The client is initialized as a starter, starting with the annotation EnableRuleLinkClient.
1 /** 2 * @author JJ 3 */ 4 @Retention() 5 @Target() 6 @Documented 7 @Import({EnableRuleLinkClientImportSelector.class}) 8 public @interface EnableRuleLinkClient { 9 10 /** 11 * The order of the client config, default is {@link Ordered#LOWEST_PRECEDENCE}, which is Integer.MAX_VALUE. 12 * @return 13 */ 14 int order() default Ordered.LOWEST_PRECEDENCE; 15 }
Apply it where it's needed most
It took about 3 weeks of spare time to build the client project, and after a lot of struggle, it was decided to use it directly for the most urgent project - business finance. Of course, I was fully prepared to switch to the RPC version at any time. Thanks to the application of DeferredResult, the changes are always synchronized within 60s, and there is also an underpinning solution: actively querying the changes every 300s, even if RuleLink is down after startup, it will not affect its operation. With this kind of preparation, there are almost no ripples after the launch. Of course, no one would worry about downtime. This can really be considered a pleasant programming trip.
Become a good programmer!