微服务优点
1,降低代码逻辑复杂度。
单个微服务模块相当于一个项目，开发人员只用关心这个模块的逻辑即可。
2，技术栈更加灵活
不同的微服务可以使用合适的语言架构实现，然后把服务注册到一个注册中心即可相互调用。
3，按需伸缩
当某一个模块达到瓶颈时，可针对模块多部署几个实例，从而提高整体吞吐量。
4，提高代码通用性
比如系统有订单，会员两个模块，后面有其他项目有会员功能，我们可以单独把会员模块拿过来使用。
缺点：
1，处理故障难度高
微服务架构是一个分布式系统，各模块运行在独立的进程中，出问题时可能需要逐个排查
2，部署工作量大
每个实例都需要配置部署和监控
3，分布式系统常见问题
模块之间通过rpc协议通信，提高了出错概率，分布式事务，分布式日志收集都是我们面临需要解决的问题。
微服务应该怎么拆分
1,根据业务拆分，根据业务功能对微服务进行才分，明确服务的业务场景，在设计时需要考虑业务的可划分性，不易将过于细小的业务片段独立成服务，做到每个模块高内聚低耦合。
2，功能拆分
在业务划分的基础上可以再进行配套服务的功能拆分，可以选择将某一个服务的相对独立的功能拆解出来单独成服务，在功能的拆分过程中需要考虑拆分后的服务所需的数据存储，运行环境是否能够满足。
3，数据拆分，在实际的运行过程中也需要考虑服务之间的数据交互，在进行服务拆分的时候，会出现一些公共的数据存在多个服务之间，这个时候可能需要按照一定的原则对数据进行拆分，一般来说数据拆分将划分为单一负责一部分数据的服务，避免多服务之间进行数据交互。
4，接口拆分
在微服务架构中服务之间通过暴露接口来实现交互，在服务划分的过程中我们还需要考虑服务间的接口拆分，拆分出来的每个服务都应该对暴露一部分接口以供其他服务调用。
接口拆分主要是根据服务的功能和使用场景进行合理的接口设计。
5，微服务的拆分粒度，2-3个人维护一个微服务。
6，一个微服务对一个数据库