Spring Cloud技术笔记系列-微服务使用背景

最近用了SpringCloud搭建了一个接口平台，一直没抽出时间总结下，计划最近写些文章总结，当然最近也没啥时间，抽空写吧，不定期更新。

今天先写个第0章，也就是为啥要用spring cloud。

背景

首先，为什么要用到springcloud。

先解释下，springcloud只是个技术，咱们用框架不能为了用而用，而是用了来解决什么问题才是最关键的。

那么为什么用呢？

springcloud提供了一整套服务治理相关的东西：

服务注册/发现

断路器

服务网关

服务跟踪

....

等等一系列内容。

所以服务是个重要的概念。

咱们先不提springcloud的事情了，先提服务——

技术进化

单一服务

技术是在不断进步的，之前大家部署情况可能是这样的：

在同一个web服务中，搭建各种各样的服务。不过经过N次开发迭代后，会发现系统越来越臃肿，耦合度越来越高，经常变成上线某个模块把整个服务搞崩了，这就悲剧了。

拆分服务

为了解决这个问题，Martin Fowler等开发大神提出了一个微服务的概念，即把各个模块按照服务进行拆分，独立部署

这样就不会因为某个模块出问题导致其他服务崩溃，减少了服务间的耦合度，各模块通过相应的接口进行通信。

调用时硬编码接口地址：

高可用问题

这样解决了耦合问题，但是又迎来了其他挑战，比如，用户登录很正常，但是数据查询数据量比较大，而且耗时，导致数据查询经常崩溃，怎么办呢？最简单的版本也算是成本最低的办法是——加机器组集群。

当数据查询的服务有多个后，调用方式就有些区别了，之前是硬编码，现在多个机器后，怎么处理呢：

Nginx等负载均衡

自己实现负载均衡

当然第一种简单些，通过nginx反代，由Nginx进行负载均衡。

为了保证nginx的高可用，搭建nginx集群。

服务优化

以上似乎解决了80%的问题，但是有几个问题：

服务列表需要手动在nginx维护，例如增加个查询的服务，修改下nginx.conf；去掉个机器，修改下nginx.conf；当一个服务的所有机器全down机后，服务熔断问题等等。

为了解决这个问题，咱们就引入了springcloud的第一个重要组件：Spring Cloud Eureka。

后续会抽出一篇文章介绍Spring Cloud Eureka，这里暂时只阐述下功能，这个组件提供了一个注册中心，提供服务发现等功能，当我们部署架构增加了这个后：

注册中心中心服务维护服务与机器之间的关系，调用端连接注册中心后，当调用某个服务时，只需要知道服务id，注册中心会返回对应的机器信息，调用端直接进行服务调用就可以了，不关心服务的具体机器信息。

服务之间由于连接了同一个注册中心，互相调用也可以只知道服务id即可。

这里需要注册中心定时进行服务列表的更新操作，子服务也需要定期上报自己的状态，以便服务器down机后，请求不在进行转发。服务恢复后，请求自动恢复。

总结

第一章大概就写这么多吧，就是简单的提供了一个模糊的概念，为什么要引入微服务，以及引入微服务后优化点，跟大家分享下