微服务--开篇

从这篇文章开始我们就进入到了微服务的世界，在后续的几篇文章中我们将学习一些微服务组件的原理，以此来达到理解微服务架构的本质。

一、案例

有一个大型商城系统，由不同开发语言设计的100多个服务组成，大部分服务之间存在调用关系，如果要将这些服务的部署改为微服务部署，几乎很难使用统一的微服务框架实现。因此使用了Nginx对这些服务进行管理，先通过本地配置文件获取要调用服务的地址，再通过代码将地址组装成URL，之后服务间的调用都通过Nginx代理。

二、传统架构的问题

案例中所说的架构方式是传统的架构方式，它存在四方面的问题。

2.1 配置繁琐，上线易出错

系统每次部署、增加服务、增减机器时都需要手工配置Nginx，并且每个环境都不一样，因此在配置时很容易出错，因此在服务器变动或网络改变时都需要把每个配置梳理一次，然后进行多次的测尺才能基本保证没什么问题，但是如果没有进行详细的检查或者某些负载均衡节点出错了就很难发现。

2.2 增加机器要重启

当系统的访问量增大时，我们需要对某些服务增加服务器，但是因为需要手动配置Nginx，因此稍不留意一同就会出错，并且系统一旦出错就要重新Nginx，如果重启失败就会产生很大的影响。所以要在短时间内加服务器并保证配置准确无误，是一个很难的过程。

2.3 单点负载均衡

所有的系统都要经过Nginx代理，因此Nginx很容易成为整个系统的瓶颈，如果Nginx配置出了问题，那么所有服务都将不可用。这时一定有小伙伴说让每个服务都拥有自己的Nginx