今天接待了一个原来从腾讯离职的合作伙伴团队，向我们展示了PAAS平台合作的意向，其中“微服务平台”引起了我们的关注。在大型的项目中，消息中间件、微服务是少不了的关键词。虽然我们在实际的企业案例中见得不多，但这也证明不少政府、国企的信息化系统中仍然是垂直系统，缺少横向扩展能力，与互联网企业的信息化建设水平仍相差不少。为提前储备一些知识，今天我们来简单分析一下微服务。
       
         一、微服务与SOA有什么区别
        虽然网上的知识讲得很多，对我留下印象最深的两点。1、微服务的服务颗粒度更小，一个简单的功能就可以封装成一个服务，并进行服务的组织。2、微服务的服务路由不再经过注册中心转发，相比SOA的重度注册中心机制，微服务的转发效率、稳定性更高。
       
         二、微服务的工作机制是什么
        1、服务提供者provider配置XML文件，将服务按指定协议发布至注册中心Registry。
        2、消费者Consumer连接注册中心，获取（订阅）指定服务的地址等路由信息。
        3、服务注册中心根据订阅信息，动态向指定消息者推送服务地址信息。
        4、Consumer直接与Provider取得RPC服务。并根据路由策略，从本地缓存的服务提供者列表中选择一个服务提供者。
    
         三、微服务的路由调度策略大有文章
        1、采用F5等硬件进行Consumer与多个Provider的连接，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。
        2、在Consumer中内嵌软件LB，进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案
        3、主机独立 LB 进程方案。该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡。

        四、微服务后管理难度增大
        1、单体应用被微服务化后，很有可能从原来的一个程序包分成了 10 个、20 个甚至更多的程序包。那么，我们首先遇到的麻烦就是部署工作直接扩大了 10 - 20 倍。这时，持续集成的方法和工具就成了实施微服务架构的前提条件。我们可以利用基于 Docker 的容器服务平台自动部署整个系统的微服务。
        2、微服务架构的运维问题，主要是相对于单体架构来说的。因为实施微服务架构后，整个系统的模块一下子比原来多了很多，模块变多后，部署和维护的工作量都会变大。所以，解决运维难的问题，可以先从自动化 的角度来解决。