微服务相关知识

参考：http://martinfowler.com/articles/microservices.html

组件可以分为服务组件和library组件，它们的区别在于：

1、服务组件：独立于用户程序运行（单独一个进程），用户程序通过特定协议向服务组件（进程）请求特定服务；

2、library组件：被链接到用户程序中，通过内存中的函数调用来执行特定功能；

一个服务对应着一个运行的进程，或者多个进程（如一个服务处理进程和一个该服务专用的数据库进程）。

传统软件工程中，一个组织设计的系统架构实际上就是真实反应了该组织层次的结构，如下图。-- Melvyn Conway, 1967

而微服务架构的设计原则，却是按照业务需求和能力来进行划分的，如下图：

这种设计将应用系统按照独立功能进行划分成服务，每个服务都是一个board-stack子系统，即该服务中包含了应用程序中的所有层级结构（前端UI，中间件，数据库部分）。

对应的，开发此类服务的团队也是具有完整编制的项目团队，包括了：开发工程师（前端，中间件数据工程师），测试工程师以及项目管理人员。

服务之间的通信：

摈弃传统SOA中的ESB（Enterprise Service Bus），原因：ESB集中管理，违背了微服务分布式架构的原则。

使用轻量级的REST协议来进行服务之间的通信。常用协议有：HTTP协议（HTTP resource API）和轻量级消息机制（Dumb）。

注：Dumb是一个消息路由器，是 RabbitMQ or ZeroMQ的简单实现，提供可靠的异步传输机制。

The infrastructure chosen is typically dumb (dumb as in acts as a message router only) - simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric - the smarts still live in the end points that are producing
and consuming messages; in the services.
http://www.tuicool.com/articles/YjiI7z 该文章不推荐使用Dumb。原因是Dumb会引入集中管理和消息的有状态化。

（If we take a step back and compare
notes between the ThoughtWorks piece and Janakiram’s, however, a more useful set of
architectural principles
emerge: horizontal scalability. Stateless communications.
Event-driven, reactive interactions. Asynchronous interactions
that favor eventually consistent data. In other words, web scale .

While it’s true that we don’t want centralized, stateful orchestration of services, we also don’t want to limit our microservice interactions to the extent that they are “dumb.” Rather, we simply have a new way of thinking
about “smart” pipes – microservice integration that is architected following web scale, cloud-centric principles.）