2015年第一次在工作中用到了Spring Boot，当时正在查一些Spring Batch还有Spring LDAP的特性，误打误撞看到Spring Boot，再到Spring Cloud，当然加上对Netflix的无限崇拜，开始了解，使用和探索微服务的架构。买过很多书，最值得反复读的无非是这本微服务设计：
真心写的好。不论他的定义像Martin Flower说的还是后人理解的细粒度SOA，也不论是Docker等容器化技术成就了微服务，还是微服务推进了Docker，微服务架构或模式的出现的确在伴随各种AS（FAAS, CAAS, SAAS, PAAS, IAAS）一如雨后春笋般的成长。总之，从软件设计的角度去看，微服务不仅仅是编写代码，而是要从业务领域着眼看待系统要解决的问题（插一句，做了16、7年软件，我一直秉承Business Values decide your system's function.技术人员了解场景，熟悉业务是必须的。这也是我在后来组建团队时对架构师的重要职责定位，确保技术团队有共通的技术愿景并使用合适的计算机技能，向客户交付有商用价值的系统。听起来像废话，但实际上，如果在需求讨论时真的有人冒出一句业务人员不懂技术，那是不是也应该反思一下技术人员是否就懂业务呢，如果能修改业务流程或审批方式是不是可以不用做系统。好的技术人员提供的是完成业务的技术解决方案，不是一味的服从，也不是拿技术名词回怼。特别是，我们学习业务比业务人员学习天书般的代码容易的多 - 又扯远了。）
在整体微服务的架构下，要考虑
1）、服务粒度的拆分：要避免微服务承担太多的职能，这也能帮助降低整个应用程序中断的风险
2）、服务管理的复杂度：保障多个服务实例可以快速启动和关闭，能方便管理服务调用的物理细节
3）、弹性设计：如何绕过Failed Down Service，并保证服务的完整性
4）、可重复和可伸缩性：比如确认Dev环境和生产环境的一致性，如何合理使用消息队列来最小化服务之间的直接依赖关系等等。
还有其他很多因素（合理API设计，分布式事务，对持续集成的支持等等），不一一赘述了。但是，必须提一下，Spring Boot， Spring Cloud的关系，先说一句他们都是跟Spring有关的框架但两者没有必然联系，前者注重内部服务功能及CRUD模块的构建，后者关心是服务与服务之间的粘合，后者更像一个整体的分布式框架（Ribbon【客户端负载均衡、重试机制】Hystrix【服务降级、服务熔断、请求缓存、请求合并、依赖隔离】Feign【Ribbon跟Hystrix的整合】Bus【消息总线】Sleuth【分布式服务管理器】Eureka，【服务注册中心，基础服务保护、停止更新2.x版本不怕，我们有更好用的Consul】Zuul【API服务网关，服务路由与过滤分发】Stream【消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区】Spring Config【统一配置管理】）的确不是一个东东。狭义上说，Spring Cloud 来开发微服务会依赖Spring Boot的工具箱。下面是几张关于几个核心组件的原理图：
a)、Zuul：很容易理解的一张图，Pre-Filter， Post-Filter，Routing Filter；熟悉Servlet的同学们看起来更Easy
b）、Eureka：服务发现，服务注册，一定要了解它和传统的负载均衡Load Balancer不一样，不一样，不一样。设计理念就不同，不论nginx， HAProxy都不是为了快速注册和注销服务设计的，根儿就不同；同时这些负载均衡由于需要为服务消费者的请求映射物理服务，无疑增加了系统的复杂度特别是手工添加的那些映射规则。在云计算环境下的服务注册，必须满足高可用、点对点、高容错、强弹性（提供缓存服务还能做逐步降级）。本身它不存在类似Zookeeper那样的leader选举机制，它也不是基于Paxos协议的，更加关注AP而不是Zookeeper的CP（不是处不处CP的CP）
c）、Ribbon：服务load balancer，一般都和Eureka一起使用，在很多应用中利用@LoadBalanced注释来创建支持Ribbon的RestTemplate类（这种情况下，我们可以不用再加入@EnableDiscoveryClient or @EnableFeignClients）
d）、Hystrix：熔断器，非常巧妙的设计，保障了客户端的弹性。试想一下微服务的调用链中互相调用中的阻塞情况，如果能及时将实际调用委托给Hystrix，并将它包装在独立于原始调用者的线程中，客户就不必等待整个阻塞后的调用结果。实际使用过程中，@HystrixCommand的方法注解就达到了目的，只要定义合适的fallbackMethod，就算大功告成。想用好Hystrix，需要更多了解HystrixProperty的配置内容，在生产环境进行配置时，一定注意三点：整个应用程序级别的默认值、类级别的默认值、类中定义的线程池级别（很重要）。同时，由于Hystrix可以使用两种隔离级别（Thread、Semaphore）当然连Hystrix开发团队都建议使用Thread隔离方式是有道理的，学习的同时建议也了解一下ThreadLocal原理，对解释Hystrix隔离机制很有帮助。自身的原理如下：
e）、Sleuth：服务的跟踪检测，配合Zipkin效果更佳（突然想起来，在后来进入的那家互金公司里面设计GlobalID的初衷）。
另外，再膜拜一下 Netflix 全是经典，爱不释手！当然，以前一直不理解为啥好多Netflix项目都针对AWS专门写一些包，2018年当阿里Submit Spring Cloud Alibaba后，才懂。相信这样能卖出更多的阿里云，当然阿里这样工程师文化的科技公司值得尊敬。（突然想起来16年给我200多人的研发团队专门做过Netflix的培训，现在还记忆犹新，时间过的好快）【另外，由于工作需要，最近一直在研究他家的Genie ，有同好的可以一起研究。】
其实关于Spring Cloud的话题，还有很多，比如部署，Spring Config，Spring Cloud Stream跟各种MessageQueue的集成包括MapR，好在网上很多实例，况且本来是想说说Node.js的，似乎这个前戏有点长，下一篇争取尽力围绕Node.js怎么构建微服务展开，不说太多废话，也请读者见谅。
- Leon 2019-2-5
