为什么要用微服务？

从传统单体架构，到集群架构，再到微服务架构过程

单体架构

1. 有单点问题，如果宕机所有的服务都不可用
2. 所有业务的功能模块都聚集在一起，如果代码量多，功能之前如果有很多共同的代码，不同业务的需求开发同时进行的时候，维护起来有点麻烦
3. 由于是单体，对请求的并发量，有限制，一个tomcat，并发量千级左右
4. 由于代码都聚集在一起，部署慢
5. 修改bug，牵扯的可能性的代码有很多，修个bug可能需要把所有功能模块都测试一遍
6. 扩展成本高，根据单体架构图  假设用户模块是一个CPU密集型的模块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU 更牛逼的内存 更牛逼的磁盘  价格蹭蹭的往上涨。
7. 前后端不分离，后端开发人员可能要具备相应的前端知识

适用于：

1. 业务稳定，运行稳定，就是修修bug ，改改数据
2. 迭代周期长 发版频率 一二个月一次.

集群架构

集群架构只是改善了，单体架构的单点故障问题和提高请求的并发数

微服务 

微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是 微服务. 

微服务拆分原则：

1. 单一微服务高内聚，微服务之间低耦合，避免出现双向依赖，环形依赖，避免微服务之间频繁调用
2. 根据业务模块划分，对数据库进行拆分
3. 针对应用性能拆分，比如有些功能是CPU密集型应用，如对大量数据进行频繁计算的模块，对硬件要求比较高，有些是IO密集型的对硬件成本要求不高的，如文件上传，下载服务
4. 应循序渐进的进行拆分，避免应用实例爆发式的增长，对部署，测试都有一定的压力，可以先把一些非核心业务进行依次拆分，也避免影响日常的需求迭代
5. 服务接口要具备可拓展性，微服务之间的调用接口参数应用统一对象来进行传参，必要时对对象添加泛型的支持，统一的序列化和反序列化方式
6. 服务拆分粒度要适中，拆分粒度不是越细越好，粒度需要符合弓箭原理及三个火枪手原则弓箭原理就是业务复杂度越高，团队人员越多，拆分出来的微服务可以越多三个火枪手原则是，一个微服务2-3个人开发维护最合适

优点:

1. 每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码 需要了解整个系统)
2. 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了）
3.  微服务能够被2-5个人的小团队开发，提高效率
4. 按需伸缩
5. 一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.

缺点:

1. 增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkis )
2. 服务之间相互调用，增加通信成本
3. 数据一致性问题(分布式事物问题)
4. 系能监控等,问题定位

微服务的适用场景

1. 大型复杂的项目
2. 快速迭代的项目
3. 并发高的项目