spring cloud

微服务架构理论引入
系统架构
传统架构

优化
即将到达瓶颈的时候进行优化，禁止过度优化。

将不同服务放在不同的服务器

做一个缓存

增加集群

Sql优化：读写分离

如：

分库
垂直分库：根据数据业务逻辑的相关性，把数据进行切分。如：股票一个mysql，保险一个mysql，每个业务一个mysql，写入数据时不会发生竞争。

切表：
库内切表：表数据大，切完后，表还在这个数据库中。
分库切表：表数据大，切完后，表放在一个新的mysql中。
数据库的压力不大，只是为了查询方便，可以使用库内切表；数据库的压力大，写入时形成竞争，可以使用分库切表。

反向代理
优化负载均衡

一直为web服务器和sql承担更多的并发量做优化

DNS轮询


分离

微服务

抽离

微服务：与传统意义的服务相比，代码更小，功能更单一，将代码抽离出来，减轻升级的压力。

企业级消息总线ESB

问题：如销售产品公司，旺季的时候请求是翻倍的，需要更多的服务器，服务器也需要部署，部署时会遇到问题（在windows写的，在linux运行时可能会遇到问题），所以需要考虑运行环境的隔离（不会因为环境而导致无法运行）。

容器化技术（docker）：
快速部署+自动化运维工具（ansible）服务器，先安装docker，，再拷镜像可以实现环境隔离

问题：业务量进入淡季，不需要更多的服务器，大量的服务器从哪里来

系统架构的弹性伸缩

微服务架构
1 服务更加细化
2 可以使系统分工明确
3 服务相互协调、相互配合

微服务概念
微服务架构是一种架构模式，它提倡将单一程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值，每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESULTFUL ATI），每个服务都围绕着具体业务进行构建，并且能够被独立得部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该服务，在所有情况下，每个任务代表着一个小的业务能力。

耦合：两个服务的关联度，完全耦合，松耦合，完全解耦

Springboot：springBoot是一个框架，一种全新的编程规范，它的产生简化了框架的使用，所谓简化是指简化了spring众多框架中所需的大量且繁琐的配置文件，所以springboot是一个服务于框架的框架，服务范围是简化配置文件。
Springcloud：sprin cloud基于springboot提供了一整套微服务的解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件。
Springcloud利用springboot的开发便利性巧妙的简化了分布式系统的基础设施开发，springcloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线，他们都可以用springboot的开发风格做到一键启动和部署。
Springboot与springcloud 的区别：
springboot：专注于快速方便的开发单个个体微服务（关注微观）
Springcloud：关注全局的微服务协调治理框架，将springboot开发的一个个单体微服务组合并管理起来（关注宏观）
Springboot可以离开springcloud独立使用，但是springcloud不可以离开springboot，属于依赖关系。

Springcloud组件：
Fegin（接口调用）：微服务之间通过rest接口通讯，springcloud提供fegin框架来支持rest的调用，fegin使得不同进程的rest接口调用得以用优雅的方式进行，这种优雅表现的就像一个进程调用一样。（简化微服务的通信过程）
Eureka（注册发现）：微服务模式下，一个大的web应用通常都被拆分为很多比较小的web应用（服务），这个时候就需要有一个地方保存这些服务的相关信息，才能让各个小的应用彼此知道对方，这个时候就需要在注册中心注册自己的信息（ip地址，编口号，服务名称等信息），注册中心将他们保存起来，服务间相互调用的时候，通过服务名称就可以到注册中心找到对应的服务信息，从而进行通讯。注册与发现服务为微服务之间的调用带来了方便，解决了硬编码（不可变）的问题。服务间只通过对方的服务id，而无需知其ip和端口即可以获取对方服务。
Ribbon（负载均衡）：ribbon是netflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。为ribbon配置服务提供者的地址列表后，ribbon就可基于某种负载均衡算法，自动的帮助服务消费者去请求。Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机等。当然，我们也可以为ribbon实现自定义的负载均衡算法，在springcloud中，当ribbon与eureka配合使用时，ribbon可自动从eurekaserver获取服务提供者的地址列表，并基于负载均衡算法，请求其中一个服务提供者的实例（为了服务的可靠性，一个微服务可能部署多个实例）
Hystrix（熔断器）：当服务提供者响应非常缓慢，那么消费者对提供者的请求就会被强制等待，直到提供者响应或超时，在高负载场景下，如果不做任何处理，此类问题可能会导致服务提供者的资源耗竭甚至整个系统的崩溃（雪崩效应），hystrix正是为了防止此类问题发生。Hsyrix是由netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。
Zuul（微服务网关）：不同的微服务一般会有不同的网路地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP，可能调用多个微服务的接口才能完成一次购票的业务流程，如果让客户端直接与各个微服务通信，会有以下的问题：
客户端会多次请求不同的微服务，增加了客户端的复杂性
存在跨域请求，在一定场景下处理相对复杂
认证复杂，每个服务都需要独立验证
某些微服务可能使用了对防火墙/浏览器不友好的协议，直接访问时会有一定的困难
以上问题可借助微服务网关解决
微服务网关是介于客户端和服务器之间的中间层，所有的外部请求都会先经过微服务网关，使用微服务网关后，微服务网关将封装应用程序的内部结构，客户端只用跟网关交互，而无须直接调用特定微服务的接口。这样，开发就可以得到简化，不仅如此，使用微服务网关还有以下优点：
易于监控：可在微服务网关收集监控数据并将其推送到外部系统进行分析。
易于认证：可在微服务网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行验证。
减少了客户端与各个微服务之间的交互次数。

Spring cloud bus（统一配置服务）：对于服务的单体应用，常使用配置文件管理所有配置。例如一个springboot开发的单体应用，可将配置内容放在application.yml文件中。如果需要切换环境，可设置多个profile，并在启动应用时指定spring.profiles.active=[profile]。然而，在微服务架构中，微服务的配置管理一般有以下需求：
集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务，因此集中管理配置是非常有必要的。
不同环境，不同配置。例如，数据源配置在不同的环境（开发、测试、预发布、生产等）中是不同的。
运行期间可动态调整。例如，可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不停止微服务。
配置修改后可自动更新。例如配置内容发生变化，微服务能够自动更新配置
综上所述，对于微服务架构而言，一个通用的配置管理机制是必不可少的。常见做法是使用配置服务器管理配置。Spring cloud bus 利用git或svn等管理配置，采用kafka或者rabbitMQ等消息总线通知所有应用，从而实现配置的自动更新并且刷新所有微服务实例的配置

Sleuth+zipkin（跟踪服务）：sleuth和zipkin结合使用可以通过图形化的界面查看微服务请求的延迟情况以及各个微服务的依赖情况，可以描绘出微服务系统的拓扑图，也可以根据耗时分析来做对某个微服务的优化。