基于kubernetes和SpringCloud微服务构建方案

很久没有写博客了，不是因为最近学习松懈，而是因为发现自己以前写的博客大多都比较水，真正有意义、有价值的文章需要大量的学习与时间去积淀。以后尽量提高自己博客的质量，走的再远，工作再忙，也要坚持看书，坚持学习，成长的道路有多长？我想大概是一生。这篇文章算是我这段时间对微服务学习的一个小小成果吧！

微服务是什么?

我第一次接触到这个词汇，以为是一个基于微信的服务，听起来感觉有些low。其实不然。微服务是一种架构模式，一种分布式的架构风格。顾名思义，micro service，将一个庞大的单体应用拆分成若干个“微小”的服务，服务间通过进程通讯完成原本在单体应用中的调用。其中必要的六个基本技术为：1、服务注册与发现；2、进程间通信；3、负载均衡；4、分布式配置中心；5、熔断器；6、网关路由。根据以上六点，以及现有的优秀开源技术，在技术选型上，稍微做下排列组合，你可能好几个月都试不完。之前没有了解的朋友可以阅读一下Chris Richardson 大师的微服务系列文集，对微服务会有一个初步的认识。也欢迎你与我，一同探讨微服务的技术选型，以及高可用方案。

初次尝试——遇见Spring Cloud

国内已经有一些公司使用springcloud实现微服务。我开始调研的时候，也在SpringCloud的体系里花了一些时间，拿出了一套基于SpringCloud+Docker的方案。SpringCloud整合了Netflix公司的一套组件。国外Netflix公司也算是比较早实践微服务的公司了，Netflix的一套开源项目，为微服务提供了比较完善的方案。我之前拿出的SpringCloud微服务实现方案，大部分的技术都是来源于Netflix

• 注册中心——Eureka

之前我是选用Netflix公司提供的eureka作为注册中心。在以前，我接触的分布式体系大多数是一个zookeeper＋dubbo的组合。目前国内短期内还是dubbo的天下。zookeeper也常常被用作注册中心，在国内的使用率非常高。注册中心可以说的上是一个微服务体系的核心，它承载了很多的调度与负载。在分布式领域有个著名的CAP定理（C：数据一致性；A：服务可用性；P：服务队网络分区故障的容错性，这三点一般不能同时满足，最多同时满足两个）。为什么不使用zookeeper而使用eureka呢？答案就从CAP定理中去寻找，显然zk是一个CP，为了保证数据的一致性，zk有一个选举leader节点的过程，了解zk的朋友一定知道，zk对于leader的选举，有一个“法定人数”：n+1，如果达不到这个“法定人数”，这个网络分区就会从zk中断开，也就不能提供相应的service发现服务了。显然，这不是我们想要看到的结果。

再来看看Eureka，它是一个典型的客户端发现模式，且是自注册的。

再者，它是一个AP，可以更好的保证系统的可用性。正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务，如果再eureka中注册的服务，它的“心跳”变得迟缓，Eureka会将其剔除管理范围。有的朋友可能就会问，那如果也是因为网络问题，eureka服务器失去了客户端大量的心跳，可怎么办？Netflix充分考虑到了这个问题，Eureka存在自我保护机制，当一段时间内，客户端提供的心跳低于80，将会自动进入自我保护模式，将该分片保护起