Micro-Service Best Practices _ system architecture

Article Source: http://www.oschina.net/translate/cracking-microservices-practices?cmp

I used it when I didn't know what a micro-service architecture was. Previously, I wrote some plumbing programs (pipeline application), which consisted of modules interacting with each other and the queue. Since then, a group of ThoughtWorks experts have also discussed micro-services. Fred George[1], then James Lewis[2, and Martin fowler[3] are blogging about micro services, making micro services the next buzzword, and now every company wants to use some micro-services.

Now there are some tags on it: endorsements,likes,trainings, even two day conferences. The more you hear about it, the more you realize that Apach camel is increasingly paired with this style of procedure. In this blog post, we can see that the Apach Camel Framework can help us create a micro-service-style application with a few lines of Java code.

Micro Service Practice

There is nothing new in the micro-service architecture. Many similar applications have been designed and implemented long ago. Micro-service is a new term that describes a software architecture that has certain characteristics and obeys certain principles. It is an architectural style: An application or software consists of a number of separate services that communicate between services in an event-based lightweight protocol. In the same way, TDD helps us create a single class of responsibilities, and the micro-service principle can guide us through the creation of simple applications at the system level.

In this article, we will not discuss the principles or characteristics of micro-service, nor discuss whether it is a way to implement SOA or a new software design process, we just look at the common practices of micro-service and how Apache Camel can help us achieve micro services. There is no authoritative definition of micro-service now, but if you have seen the article or video mentioned above, you will find that these are common practices for micro-services:

1. Small scale.

The basic principle of micro-service is that each application is small, focused on one thing and doing it very well. From ten Loc to 1000, the size of the constituent program has been a contentious topic. I am personally inclined to think that the size of the program should just hold your head. A lot of people have a big head, so it's a controversial topic (this is black humor and can be ignored). I think that once a program has done only one thing and done it well, it's just a good scale, not a nano service (Nanoservice). The very fundamental principle of microservices says this each application are small in size and it only does one thing and Does it.

Camel programs are inherently small in size. A camlecontext with both error handling and helper beans is about 100LOC (line of code). Because of the camel DSLs and URIs to extract the terminal address, Accepting events via HTTP or JMS, unpack, and send response feedback is no more than 50 lines of code (LOC). This is small enough to understand end-to-end, and there's no shame in rewriting or discarding such small code.

2. Has a transaction boundary.

An application consisting of multiple micro-services forms a system of final consistency, and the overall state of a large system consisting of many such systems is unknowable at a given point in time. This is tantamount to setting yourself a barrier that makes it harder for teams that are unfamiliar with distributed applications to understand and then adopt a micro-service architecture. Even if the state of the entire system is not fixed, it is important to use transaction boundaries to define the attribution of the message.

It is not easy to ensure transactional operations in heterogeneous systems, but Camel has strong transactional support capabilities. Camel has terminals that can participate in transactions, transactional routing and error handling, power consumer and compensation operations, all of which can help developers easily create services with transactional behavior.

3. Self-monitoring.

This is one of my favorite features of micro-service. A service should provide information to describe the state of the various resources it relies on and its own state. These are statistical information, such as the average time to process a message, the maximum minimum time, the number of successful and failed messages, tracking a message, memory usage, and so on.

This is the camel function of the Open box. Each camel application collects JMX statistics by default, including information about the entire application, private routing information, terminals, and consumer component information. It will tell you how many messages have been successfully processed, where there have been few failures, where they have failed, and so on. These APIs are not read-only, and JMX allows you to update and tweak your programs during run time, which means you can use the same set of APIs to adjust your application based on these statistics. These statistics can also be accessed using other tools, such as Jconsole,visualvm,hyperic HQ, and can also be accessed using Jolokia via HTTP, or provide information to a great Web UI component called Hawtio[6.

Figure 1:hawtio

If the out-of-the-box features do not meet your personalized needs, there are some extensions to choose from, such as Nagios, JMX, Amazon Cloud monitoring components and custom event interceptors.

The log of the message type application is another challenge, but the camel MDC log, combined with the throughput logger, makes it easy to track some information or get statistics on the aggregation of the log information.

5. Designed to handle failure.

A single micro service may be down or unresponsive for a period of time, but this should not cause the entire system to be unavailable. So micro-services should be able to tolerate disaster and recover when possible.

Camel also has a number of useful tools and models to deal with these situations. Dead Letter channel ensures that messages are not lost when the transmission fails, and that when some errors are generated, the retry policy can send a message multiple times with the help of custom fallback methods and conflict avoidance policies. Patterns, such as load balancers that support circuit breaker [7], such as failover (disaster tolerance) and other strategies, such as throttler (throttle valve), ensure that a node is not overloaded, and Detour, Sampler are also used in a variety of error situations. So, what is the reason not to use these, but to reinvent the wheel in each service?

6. High configurable nature.

The same program should achieve high availability through simple configuration, it should be easy to expand to achieve reliability or improve throughput, or in other words: you can have varying degrees of freedom by configuration. When using DSL to create a camel application, all we do is define message flow, configure various terminals and other features of the configuration application. So the camel application is designed to be highly configurable. Once all of these options have been removed to the configuration component, the application can be configured and redeployed as expected without touching the source code. Camel is so configurable that you can replace one terminal with another (such as using JMS to replace HTTP terminals) without even modifying any program code, as we'll talk about here.

7. With intelligent terminals.

Rather than using Web services, micro services tend to use restful protocols and lightweight messaging mechanisms. Camel support everything. It does not require other frameworks to support HTTP. It has such components as asynchronous HTTP, GAE URL Acquisition Services, Apache http Client, Jetty, Netty, Servlet, Restlet, CXF, and serialization/deserialization of messages in a variety of data formats. With regard to support for queues, there are a variety of out-of-the-box connectors, such as JMS, ActiveMQ, ZeroMQ, Amazon SQS, Amazon SNS, AMQP, Kestrel, Kafka, Stomp, which you can name.

8. can be tested.

There is no particular unified view of this feature. Some people tend to rely on business metrics for not doing tests at all. Some people simply can't stand the bad business metrics. I like TDD (test-driven development), like being able to test my business pojo without relying on the actual message flow, so it's no value to test the message flow by simulating an external terminal. Camel can support intercepting and simulating terminals, simulating events, and easily validating expected results in testing. Having a well tested micro-service is the only guarantee that the entire system will function properly. 9. Separate supply.

The most important feature of micro-services is that services are isolated from each other and are usually run as stand-alone Java applications. Camel can be embedded in a SPRING,OSGI or Web container. Of course camel can also be built into a jetty terminal, and then run as a standalone Java application. But without a centralized management tool, managing multiple stand-alone applications is a tricky task. And that's why the fabric8[8 is developed. The FABRIC8 is developed by the same gang that developed the camel, and is maintained by Red Hat JBoss. It is a composite Java application Provisioning and management tool that can deploy and manage multiple Java containers and stand-alone processes. To get an insight into Fabric8, you can refer to the comment [9], which is a good article written by Christian Posta.

10. Language neutrality.

A small, stand-alone application model allows developers to use the most appropriate language for specific tasks. Camel supports XML, Java, Scala, groovy, and other DSL (domain-specific languages) with specific syntax and capabilities. But if you don't want to use camel when dealing with a micro-service, you can still use FABRIC8 to deploy and manage applications written in other languages and run them in a local process.

Summary: Micro-service does not have a strict definition, and this is just a kind of beauty. It's a lightweight way to implement SOA, and it's easy to use. The same is true of Apache camel. It does not support the full nature of the ESB, but it can be part of the JBoss fuse. The Apache camel is not a project driven by strictly defined specifications, but a lightweight tool that developers love.

Resources

[1] micro­ Service architecture by Fred George Https://www.youtube.com/watch?v=2rKEveL55TY

[2] micro­ Services ­ Java, the UNIX Way, by James Lewis (video) http://jz13.java.no/presentation.html?id=2a7b489a

[3] microservices, by Martin Fowler http://martinfowler.com/articles/microservices.html

[4]μcon:the microservices Conference Https://skillsmatter.com/conferences/6312­mucon

[5} nanoservices Http://arnon.me/wp­content/uploads/2010/10/Nanoservices.pdf

[6] Hawtio http://hawt.io/

[7] Circuit breaker pattern in Apache Camel by Bilgin Ibryam Http://www.ofbizian.com/2014/04/circuit­breaker ­pattern-in­apache­camel.html

[8] Fabric8 http://fabric8.io/

[9] Meet Fabric8:an Open­source integration Platform by Christian Posta http://www.christianposta.com/blog/?p=376

[Ten] Micro Services the easy way with Fabric8 by James Strachan Http://macstrac.blogspot.co.uk/2014/05/micro-services& ; shy;with­fabric8.html