我正在参加「掘金·启航计划」
从这篇文章开始我们就进入到了微服务的世界，在后续的几篇文章中我们将学习一些微服务组件的原理，以此来达到理解微服务架构的本质。
一、案例
有一个大型商城系统，由不同开发语言设计的100多个服务组成，大部分服务之间存在调用关系，如果要将这些服务的部署改为微服务部署，几乎很难使用统一的微服务框架实现。因此使用了Nginx对这些服务进行管理，先通过本地配置文件获取要调用服务的地址，再通过代码将地址组装成URL，之后服务间的调用都通过Nginx代理。
二、传统架构的问题
案例中所说的架构方式是传统的架构方式，它存在四方面的问题。
2.1 配置繁琐，上线易出错
系统每次部署、增加服务、增减机器时都需要手工配置Nginx，并且每个环境都不一样，因此在配置时很容易出错，因此在服务器变动或网络改变时都需要把每个配置梳理一次，然后进行多次的测尺才能基本保证没什么问题，但是如果没有进行详细的检查或者某些负载均衡节点出错了就很难发现。
2.2 增加机器要重启
当系统的访问量增大时，我们需要对某些服务增加服务器，但是因为需要手动配置Nginx，因此稍不留意一同就会出错，并且系统一旦出错就要重新Nginx，如果重启失败就会产生很大的影响。所以要在短时间内加服务器并保证配置准确无误，是一个很难的过程。
2.3 单点负载均衡
所有的系统都要经过Nginx代理，因此Nginx很容易成为整个系统的瓶颈，如果Nginx配置出了问题，那么所有服务都将不可用。这时一定有小伙伴说让每个服务都拥有自己的Nginx，虽然这样避免了Nginx出错导致整个系统不可用的情况，但是因为有很多Nginx因此维护起来很繁琐，且更容易出错。
2.4 管理困难
在大部分公司内，所作的系统必须合规，因此需要经常对整个系统调用库进行升级。要对整个系统升级就需要记录下来所有的服务地址，服务地址记录要定期整理以保证不会遗漏任何一个服务。记录服务地址的方式有三种：
- 每个服务自动将自己和IP地址注册到协调服务中，然后协调服务将所有服务的清单以及每个服务的服务器节点列表推送给所有的服务，服务会自己控制调用哪个服务的哪个节点。
- 将所有服务都部署在容器上，然后利用K8S的Service和Pod特性进行服务注册发现。
- 每个服务自动将自己和IP地址注册到协调服务中，然后设计一个自动获取服务列表的工具，根据列表自动更新Nginx配置，更新完成再重启即可。
这三种方案中不推荐使用第三种，因为它并没有解决Nginx单点瓶颈以及增加服务器后需要重启的问题，
三、微服务注意事项
3.1 中心存储服务使用什么技术
这个问题我们可以使用Redis来解决，但是哈需要考虑以下两个问题。
- 服务变更后需要实时推送给所有服务；
- 监听所有服务的状态，如果某个服务不可用要及时通知其他服务。
对于这两个问题 ，分布式协调服务正好满足。
3.2 使用什么分布式协调服务
关于使用什么分布式协调服务，我们不仅仅要考虑技术本身，还要考虑技术团队的技术背景，一般来说如果技术团队没有使用过任何分布式协调服务，推荐使用 nacos，主要是因为它带有配置中心，可以做到一个中间件实现两个功能，性价比很高，另一个原因是在一致性方面它既满足AP又满足CP。
四、总结
本篇文章大致讲解了一下传统架构的问题和微服务注意事项。
