认识微服务架构

1.1、单体应用机构存在的问题

1. 复杂性高：大型项目包含的模块多；
2. 技术债务：人员更替快，需求变更快；
3. 部署频率低：代码增多会导致项目的构建和部署花费大量时间，每次修改需求问题的时候都需要重新部署项目，影响范围大，风险高，在遇到大量修改代码需求的时候部署会导致出错概率高；
4. 可靠性差：某个应用的bug会导致整个系统奔溃，换言之bug的影像范围可能会很大。

1.2、什么是微服务

1. 微服务架构风格简单来说就是把一个大项目分成多个小项目来构建，每个服务运行在自己的进程中；这里说的小项目是指每个服务有独立的业务开发；比如：订单管理，用户管理等等；
2. 服务可以采用不同的语言开发，使用不同的数据存储技术；
3. 服务与服务之间的通信通过使用HTTP资源API来进行通信（如TEST、AMQP、STOMP、MQTT）；
4. 服务之间影像不大，bug对服务的波及范围i不会很广，有助于开发人员对项目进行维护；
5. 全自动的部署机制；

1.3、微服务架构的优点

1. 便于开发维护：微服务是把整个项目分成多个服务部署，每个服务的代码都是一个特定的业务，后期维护的时候可以针对某个问题项目进行修改，部署也只需要部署问题项目，而不像单体应用架构一样部署整个项目；
2. 单个微服务启动较快：单个服务代码量少，启动就快；
3. 局部修改容易部署：这个有点类似玉第一个优点；这大大减少了后期代码维护的工作量；
4. 技术栈不受限：服务可以使用不同的开发语言进行开发；
5. 按需伸缩：系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存，升级CPU或者是增加节点。

1.4、微服务架构的缺点

1. 运维要求高：服务越多运维投入越高；
2. 项目复杂度高：使用微服务构建的是分布式系统，对于分布式系统来说系统的容错，网络的延迟，分布式事务等都是问题；
3. 接口调整成本高：如果修改被调用的接口，那么调用了该接口的微服务都需要调整。