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 的核心概念是持续集成、持续交付和持续部署。它是作为一个面向开发和运营团队的解决方案，主要针对在集成新代码时所引发的问题（也称为：“集成地狱”）。
)
)
