1、什么是微服务
微服务（或称微服务架构）是一种云原生架构方法，在单个应用中包含众多松散耦合且可单独部署的小型组件或服务。 这些服务通常拥有自己的技术栈，包括数据库和数据管理模型；通过一个REST API、事件流和消息代理组合彼此通信；以及按照业务能力进行组织，具有通常称为有界上下文的服务分隔线。
2、为什么要使用微服务
为什么要使用微服务，这个就要结合服务的进化历史来说一说。
2.1、单实例单数据库的单体架构
早期的项目，所有数据都保存在一个数据库中，所有的服务都在集中在一套代码中，服务上安装好数据库和运行环境后，部署上对应的系统，即可以进行使用。
2.2、多实例单数据库的单体架构
随着系统用户量增加，单实例单数据库的单体架构就会出现问题，比如访问延迟、响应过慢等问题，所以，此时就会来增加服务器，使用负载均衡来提高服务性能，缓解单节点服务的压力。
2.3、多实例多数据库的单体架构
数据量再次扩大后，数据库的访问就会出现问题，此时，就会再增加数据库的实例，将新增、修改、删除等操作与查询操作分离，实现多个数据库访问，并实现数据库的主从复制。
2.4、SOA 架构
当项目需要扩展新需求时，在原来的基础上进行增加和修改，就会影响到之前的业务，那么如何处理呢，就需要引入消息总线ESB总线，将原来的服务与新的服务分开，用消息总线来进行通信。两个部分分开处理，互相不影响。
2.5、微服务架构
项目逐渐变得越来越庞大，开发人员也越来越多，团队达到了大几十人。这时，就会发现原来的服务拆分粒度太 "粗"，而且原先系统的所有流量都会经过 ESB 进行分发，造成系统的可用性下降，甚至在流量峰值出现部分节点宕机的情况，这是一大隐患。
于是， 就需要进一步拆分团队，拆分服务，将原先的服务与其他服务又进行了拆分，拆出了 10 余个服务。为了治理这些服务，就需要引入微服务架构 ，用微服务网关 与注册中心 代替原有的消息总线 ，并采用分布式部署。除此之外，一系列微服务治理框架 与 Devops 自动化运维部署 流程也随之引入，每一个微服务均通过容器化方式部署上线。
3、总结
- 单体架构：所有功能都集中在同一个项目内，统一测试，统一部署，牵一发而动全身，适合初创项目进行试错，不适合大型商业项目。
- 在此基础做的纵向升级、横向扩容、一主多从等仍然属于单体架构，因为其仍然是单一服务、单一项目。
- SOA 架构：进行了初步的服务拆分，但是服务拆分的粒度较粗，并且没有引入服务治理组件，流量集中于消息总线。
- 微服务架构 ：是 SOA 架构的升级，基本沿用了 SOA 的思想，但是服务拆分粒度更细，并且引入了服务治理组件，结合流行的容器化技术，实现 Devops 自动化部署与运维。
- Devops（Development和Operations的组合词） 是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。总是与微服务一起出现，因为 Devops 带来的是敏捷开发、更快交付，而微服务通常由各个小团队负责开发，迭代周期更快、更敏捷。
- CI/CD 是 Devops 的核心，CI/CD 是一种通过在应用开发阶段引入自动化 来频繁向客户交付应用的方法，CI/CD 的核心概念是持续集成、持续交付和持续部署。它是作为一个面向开发和运营团队的解决方案，主要针对在集成新代码时所引发的问题（也称为："集成地狱"）。