闲聊微服务之服务注册中心

   聚是一团火，散是漫天星，这是对微服务的最好完的解释了。

   服务，提供什么服务，有的叫服务中心，有的叫注册中心，有的叫服务注册中心，表达的都是同一个意思。

服务注册中心

     1 为什么需要服务注册中心

    我们总是在谈SOA，总是在谈微服务，而服务注册中心则是微服务的基础，那么为什么需要这个基础。

    微服务需要将一个一体化的应用进行拆拆拆，拆成各种微小的服务，这样有什么好处？

    首先，便于发现服务的瓶颈，对于一个一体化的应用来说，追查每一个阶段的耗时太复杂了，而拆解成微服务之后，则可以追查每个阶段的调用的耗时，可以发现系统的性能瓶颈。

    其次，发现了性能瓶颈之后，或者发现某个应用的TPS，QPS随着业务的增多，那么可以进行水平扩容，在初期阶段，性能可以接近线性增长。

    微服务，麻雀虽小，五脏俱全，团队大了怎么办？那就拆，拆成小团队进行单兵作战，从而能大大提高效率。

    那这个和服务注册中心有半毛钱关系，还是有半毛钱的。你可能说这些功能其实负载均衡也能提供，无论是高可用的冗余，还是性能的追求，但是负载均衡仅仅是为了冗余，而不是为了性能，而且最重要的区别在于，负载均衡是静态的，而服务注册中心则是动态，这就是为什么不使用负载均衡的原因。

    2 服务注册中心的名词

    服务注册中心主要分为三个部分，一个部分是服务的提供者，一个部分是服务注册中心，一个部分则是服务的消费者。

    随着业务的发展，应用越来越多，每个应用之间的交互也越来越多，从而为了解决应用之间的依赖关系，从而需要使用服务注册中心。

    在进行使用服务中心的时候，根据应用来进行划分，有的应用可能提供多个服务，有的应用也有可能消费多个服务，RPC服务调用了解一下。

    在数据流程上，服务提供者启动服务之后，会将服务注册到服务注册中心，而当服务消费者启动的时候，会从服务注册中心拉取相关的配置，放到缓存中。从本质上来说，其实也就是一个名称解析服务，因为对于服务消费者来说，首先，从服务注册中心根据服务名找到服务提供者的ip和端口，然后根据内部的调度机制，找到一个服务提供者访问，得到请求结果。

    从而，注册中心解偶了服务提供者和服务消费者之间的关系，并且支持弹性的扩容和缩容，当你扩容的时候，只要将你的服务再次扩展一个，也就会自动注册到注册中心了。

    服务发现，是站在服务消费者的角度来说，能发现服务提供者的ip增多或者减少，其实这是因为服务注册中心的主动推送的作用。

    服务注册，是站在服务生产者的角度来说，也就是服务生产者将服务注册到服务注册中心。

    服务路由，主要是将服务生产者的ip缓存在本地，然后在其中使用调度算法选择一个合适的服务提供者。

    3 从开发者的角度看

    从开发者的角度来看，在使用服务注册中心的时候，是否需要修改代码，从而分为应用内和应用外。

    我不是黄蓉，我不会武功，我不是开发，我只是瞎逼逼。

    开发关心的是，我一个系统有几个应用，几个应用提供几个服务，从而需要一个界面，能查看到相关的服务，例如应用名称，服务名称，服务提供者的数量，服务消费者提供的数量；每个应用有几个服务ip，端口等信息。

    服务调度的时候如果是使用wrr算法，那么还有一个地方能设置权重，在服务进行升级的时候，为了不影响，应该还需要提供相关的接口，关闭服务开启服务，这样才能进行服务的热升级。

    应用之间的依赖关系图，也就是应用有哪些服务，服务之间的依赖关系是啥样的，需要一个拓扑图，不然，追踪问题的时候很麻烦，而且最好还需要有埋点，从而能从每个阶段进行追踪服务。

    3 从运维侧看服务注册中心

     运维侧，主要就是解决问题，会出现哪些问题？服务未注册成功，服务注册超时，服务获取超时，服务注册中心的高可用，服务注册的中心的扩展性。

    部署，从部署的角度看运维复杂度，例如需要消耗几个服务器，需要多少cpu，内存，存储。

    升级，在进行升级的时候，是否影响服务的提供，热升级？如何做到无感升级。

    监控，需要监控哪些日志，需要监控哪些服务，自身的服务监控，注册的服务监控。

    健康检查，对各种服务的上线，下线，修改，是否能及时的通知到消费者。

    高可用，是采用三节点？还是五节点？

    在跨机房的时候，怎么做？选择zk还是consul？还是etcd？在单个机房的时候，选择consul？考虑到CAP的什么特性？跨机房的时候，运维复杂度怎么衡量？怎么取舍？

    4 注册中心

     在使用服务注册中心的时候，除了上面所讲的服务名称系统，其实还有一种，就是服务总线系统，其实这种和esb类似。

    服务总线系统和服务名称系统的主要区别就是，当请求发送给服务注册中心的时候服务中心会代替客户端进行访问相关的服务提供者，从而对于服务消费者来说，只要一次调用，即可完成，而对于服务名称系统来说，需要发起两次调用。

      哪一种更好？服务总线系统更加复杂，但是有更大的灵活性，而对于服务名称系统来说，差不多基本上要提供一个SDK，从而在升级的时候，也是麻烦，你是否需要升级客户端，接口的兼容性也是需要考虑的。

    聚是满天星，散是一团火，这样感觉也很酷，虽然是人走茶凉，但是可能散开的一个火种。

    服务中心的主要功能是配置和调度，如果服务中心本身是瓶颈怎么办？平行扩容？

    今夜的寒风将我撕碎。何以解忧，未有头绪。

标签：需要,服务,注册,中心,应用,服务提供者,闲聊
来源： https://blog.51cto.com/15060545/2651721