#Microservice Structure

The Abstract & The source

花了两个小时读完microservice，觉得这个设计思路跟罗辑思维罗胖讲的『U盘人』有类似之处，都是自带信息，随时插拔，自由协作，当然还要容错性高。

这个是原文链接，做软件设计的值得多看看，开阔开阔思路：
http://martinfowler.com/articles/microservices.html

The Good:

With a monolith any changes require a full build and deployment of the entire application. With microservices, however, you only need to redeploy the service(s) you modified.

The Bad:

The downside is that you have to worry about changes to one service breaking its consumers. The traditional integration approach is to try to deal with this problem using versioning, but the preference in the microservice world is to only use versioning as a last resort. We can avoid a lot of versioning by designing services to be as tolerant as possible to changes in their suppliers.

The Specification:

Organize around business capabilities
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
-- Melvyn Conway, 1967
对比：
Monolithic的团队注重组织分工，各司其职：

Paste_Image.png

Microservice的团队更加注重business capability：

Paste_Image.png

The Example:

The Microservice is the Evolutionary Design, or not?
The Guardian website is a good example of an application that was designed and built as a monolith, but has been evolving in a microservice direction. The monolith still is the core of the website, but they prefer to add new features by building microservices that use the monolith's API.