随着云计算业务的快速发展，国内外云计算企业的专利之争也愈发激烈。在云计算这样的技术领域，专利储备往往代表着企业最新的技术实力。华云数据本期“智汇华云”专栏将针对“浅谈微服务架构之服务发现”技术，与大家共同分享云计算领域的最新技术。
由于业务量大幅增长，华云数据决定对业务增长导致不断臃肿的单体应用进行重构，重构后的应用选择微服务架构。微服务架构最大的优势是语言的开放性，可以根据业务场景选择最合适的语言。另外对于不止一个技术栈的公司组织架构，也能带来很好的融合协作机会。华云数据的主要技术栈是JAVA，PHP。JAVA自不必多说，其微服务框架spring cloud对微服务有非常全面且完善的一条龙支持，简直是微服务架构开发的利器，而PHP则有所欠缺，特别是在服务治理部分。比如在做服务注册、发现的时候比较痛苦。
我们的方案
1、为什么要使用服务发现
下图1 ，是一个简单的高可用架构图，我们看到集群组部署有3个节点，每个节点分别部署有一个服务A。在它前面有负载均衡，以nginx做负载均衡为例，我们会在配置文件手动配置上这3个节点的服务A的地址，根据负载策略做转发。
图1
这是传统上比较常用的方式。服务的地址是固定不变的。那么如果服务的地址弹性伸缩，是可变的又如何呢?如下图2。
图2
与传统方式不同的是，服务的地址是弹性伸缩，是可变的。这种弹性带来最大的好处是服务可以根据流量、根据CPU、内存等开销，依据一定的策略，横向扩展或减少服务实例。除了能支撑大量的峰值访问，还能带来非常大的成本节约。另外特别说下，docker及其衍生出来的Kubernates之类的软件或解决方案，使得这种资源调度，弹性伸缩，架构监控等有了很好的基础层保证。回过头来说，既然服务地址可变，那么人工配置的方式肯定不行，我们需要一种自动发现服务地址变更的机制。
2、服务发现的机制及发现方式
这种机制即服务发现，也是微服务架构最常使用的技术栈。如下图 3，我们引入一个注册中心。服务实例在启动的时候自动把地址注册到注册中心，在访问相应服务的时候，先通过注册中心拿到待访问服务实例的地址，然后依据一定的策略访问即可。
图3
好处主要有两点：
1、解决上述说的服务地址变化的问题;
2、注册中心能够监测相应服务的状态，有了它，我们就能知道微服务架构中有多少个服务，版本是什么，每个服务的实例数有多少，状态如何。
服务发现有两种方式：
2.1服务端发现
1)服务实例启动时自动发布地址到注册中心。
2)客户端/服务端在调用某个服务时，带着服务名调用负载均衡器，负载均衡器接收到请求，从注册中心拿到服务地址(有多个)，根据负载策略访问某一个特定的服务。
这种方式最大的好处就是由服务端实现服务发现及负载，客户端完全不用做额外的事情，非常推荐使用此方式。如下图4。
图4
2.2客户端发现
从下图5可以看到，跟服务端发现不同的地方是，待访问服务的地址由客户端从注册中心获取，并且客户端需要实现负载(比如待访问的服务地址有3个，那么客户端需要依据一定的负载策略，找出其中一个地址进行访问)。
图5
这种方式最大的特点就是灵活，客户端或者微服务可以根据自己的业务场景选择最佳的负载策略，但是缺点也是显而易见的，客户端或微服务需要考虑负载。这在JAVA没问题，它的spring cloud框架很强大，可以支持，不过PHP及其它语言就会很痛苦，所以个人推荐使用服务端发现的方式。
如下图6方式，服务端发现可使用consul template+nginx
图6
3、工具介绍及总结
Netflix OSS 是典型的客户端发现范例;Netflix Eureka 是服务注册表，Netflix Ribbon是IPC客户端，与Eureka一起实现CLB。对docker无明确支持
Consul 是典型的服务端发现范例;通过consul template监听consul中服务地址的变动，自动生成或更新nginx.conf，并生效配置。对docker有很好的支持
微服务架构的性质决定了它的复杂性，存在成百上千个微服务，而每个微服务又可能分布在多个不同节点，所以全栈监控很重要，而服务发现则是其中很重要的一环。通过它，我们就知道整个系统有多少个微服务，版本是什么，每个服务的实例数有多少，状态如何。而这些又是一个完整自动化运维架构的基础，发挥微服务架构最大的价值非常重要，大大减少运维人员在部署、问题排查上冗余工作，大幅提升工作效率。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
