微服务（一）架构的演变以及SpringCloud部分相关组件
- 1. 架构的演变以及微服务定义
- 2. 微服务相关组件
1. 架构的演变以及微服务定义
如果是特别小的项目，可以用dubbo集成zookeeper就行。
早期是SOA架构，面向服务的开发，比如一个springboot项目，一个商城项目一个财务项目，都是依赖于一个数据库的。
上面是面向单体应用，下面是面向服务或者模块开发，两个模块组成一个项目。打成一个war包。
随着技术的前进，形成了如下的架构显示。
上面是SOA，打多个war包，两个war包独立运行，两个模块有共同依赖，假设都在商城服务中，但是从财务服务访问共同依赖，需要RPC远程调用服务。
什么是微服务？从面向需求（或者应用）这个维度进行拆分，比如抽离出一个小服务为订单服务，对比以前的服务（SOA）粒度更小。
微服务的拆分是值得关注的问题，许多业务部门招架构师都需要一定的专业背景，这不仅仅是技术上的需要，还有的是对微服务拆分的需要，否则微服务如果拆分过多，会有网络延迟，这个度需要把握好。
2. 微服务相关组件
首先需要明确一点，所有的微服务都是基于springboot的。
假设有3个支付服务，需要做负载均衡，在客户端这里，需要获取服务的列表，怎么获取服务的列表？有个中间商，注册中心，这里用到技术框架一开始为netflix Eureka，可以从Eureka中拿回来放到服务列表中，有了服务列表之后，需要调用组件，是用到netflix feign组件，发起远程调用的，feign从服务列表找一个，直接调过去了。但是调的过程中，需要做客户端的负载均衡，这个时候需要用一下netflix Ribbon，是个客户端的负载均衡，ribbon是一个尝试的功能，如果调用失败，下一次就不让fegin去调用该服务了。什么是客户端的负载均衡？可以主动选择，前提需要知道服务有多少。服务调起之后，这个时候是返回结果给客户端，之后，拿这个结果渲染结果数据。可以用json或者thymeleaf。
在这里，需要把所有结构拆分为服务提供方与服务调用方。
服务提供方：包含了fegin、ribbon以及其他组件，也就是一个springboot包含了这些。
服务调用方：为支付服务service。
服务提供方也需要做负载均衡，一个controller扛不住，需要有多个controller，这个时候需要不能直接暴露controller出来，需要做服务的负载和服务的路由以及权限的处理。这个时候加个网关层。用netflix zuul做服务的网关，所有的请求由它来路由，所谓的路由其实也就是一个URL，告诉zuul之后，用户请求的URL就能直接定位到该Controller，这里的controller可以做横向的负载（镜像）也可以做纵向的负载（不同作用）。也可以在zuul中做一些权限认证的功能，可以不用在controller层跑权限认证，网关这里是拦截一切的请求的，所有的请求都打到zuul上，如果zuul扛不住也可以做多个。在这个zuul里，可以做统一的权限处理，可以集成springcloud security与JWT。如果不用spring security或者是JWT的时候，用shiro，shiro是集成在服务提供方controller。需要独自维持会话了，需要SpringSession，这是做session共享用的，但是如果做了oauth2.0与JWT的话，就不用session共享了。Springsecuity可以用在oauth2.0也可用在RBAC中。这里都是基于拦截器的，在controller层。注意，这里的zuul做的网关其实是业务网关，在流量介入层中，还需要一个流量网关，通常是用nginx、LVS、keepalived做。流量介入层很重要，如果流量介入层扛不住，那么微服务的性能也不行了。但是流量介入层的流量网关一般很少做，因为除非是很大很大并发的项目，否则只需要业务网关就行了。
在Ribbon调服务的时候，涉及到分布式事务，分布式系统下的事务需要自己去保证了，在单机情况下，利用spring事务机制就行，但是分布式中，却不行。Alibaba Seata，也可以用Gts。调服务时候也涉及到链路追踪，如果服务调用服务再调用服务，这个里面调用多个服务，但是有异常，怎么定位？观察？所以需要链路追踪，sleuth或者是zipkin或者skywalking。也会涉及到分布式锁，zookeeper curator或者redlock。
熔断与降级，在ribbon调用服务的时候，不管后面的客户端是否可用，当服务出现长时间等待或不可用情况，能实现熔断和降级处理。Hystrix记录后面服务的状态，是否靠谱，不靠谱就熔断（再也不调，除非该服务又可以正常调用）。为了达到服务啥时候上来给hystrix知道，给每个微服务加个组件（节点信息上报功能）——acturator，这是跑在每个服务中的，提供上报信息功能，上报给hystrix，重新上线。降级：系统整体较忙的时候，让后端的某些服务不提供服务，提供降级的接口。熔断和降级其实它们的原理都相似，都是服务调用失败后的进行一些快速失败措施。但它们的出发点不一样，熔断是为了防止异常不扩散，保证系统的稳定性。而降级则是人为操作。在一些流量顶峰期，为了保证某些热门接口的正常运作，有时候会牺牲一些非核心接口，把资源全都让给热点接口，这就是服务降级。每年12306抢票的时候，大家都集中抢购那几个热门车次的车票，而如果此时有其他用户去查询几天后的非热门车票，有可能会查不出来。这就是降级的表现，在秒杀期间，其他不参与秒杀的接口停止服务，把资源都让给参与秒杀的接口。怎么发现服务是否特别忙？通过actuator上报，另外还有一个统一化的管理，所有信息提交给springcloud admin，是一个所有服务的监控平台。
处理消息：spring messaging、spring integration、apache Camel、springcloud stream，messaging是最简单的，第二层是integration，第三层是springcloud stram与camel。Messaging是对单一消息中间件的包装，给它包装成一个统一的标准，屏蔽掉了框架的差异（RQ与kafka），integration或者是camel对messaging的集成，是做EIP的，把所有的消息中间件都放到一起，作为协调者。Springcloud stream对intergration再次包装，与springboot做了整合，为了做springcloud bus。可以做企业级的消息总线。最核心的是AMQP，把所有的消息中间件集成在一起。
