标签：
引用InfoQ的一段话：
“实际上微服务本身并没有一个严格的定义，不过从很多人的反馈来看，大家都达成了这样一个共识：微服务是一种简单的应用，大概有10到100行代码。我知道使用代码行数来比较实现其实很不靠谱，因此你能理解这个意思就行，不必过分拘泥于细节。不过有一点需要注意，那就是微服务通常都是很小的，甚至是微型的。这意味着你不会在大型框架上看到很多小服务，这是不切实际的。简单与轻量级是当今的主流。“
从这当中不难看出微服务就是完成一个任务的服务和传统的SOA没啥区别。
所谓“泛域名解析”是指：利用通配符* （星号）来做次级域名以实现所有的次级域名均指向同一IP地址。
一图胜千言，先上一张结构图：
我来讲解下
其中ServicePublisher和ServiceWatcher相当于一个Zookeeper的代理。让成百上千的Service直接连接Zookeeper毕竟不是什么好事情。尤其是Zookeeper的Watcher机制存在一定的性能制约，让整个RouterMesh集群中每个RouterMesh都直接Watch变化，那性能谁用谁知道。
ServiceWatcher直接Wacth服务在Zookeeper中的变更，并同步到本地磁盘上。ServiceWather和ServiceSync使用以前提到的同步协议来完成Service的IP和Port的变更记录。
Service通过心跳通知ServicePulisher自己还活的，然后由ServicePulisher统一刷新Zookeeper中的服务节点。
RouterMesh从nginx接收到请求后找出服务所在后端的IP和Port接着转发请求。
假如我们有一个域名为mbooks.me，我们为*.api.mbooks.me进行泛域名解析。后面有服务service1...serviceN。
我们可以通过约定的方式向ZK Cluster中注册service1.api.mbooks.me一直到serviceN.api.mbooks.me。然后我们在Web页面中就可以使用了，而Nginx上面不需要任何service1.api.mbooks.me或者serviceN.api.mbooks.me的设置，只需要一条*.api.mbooks.me的设置。
RouterMesh实际上给了我们一个可以对请求过滤的机会，里面可以做一些负载均衡，断路保护，和后端服务升级的工作。同时也不需要每次都要nginx reload。
顺便说一句，RouterMesh和Nginx这层可以合并，因为使用Nginx＋Lua也能做到这些事情，并且不需要nginx reload。
标签：
原文地址：http://my.oschina.net/u/236698/blog/483044
