微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
微服务每个模块都可以使用不同的开发技术，开发模式更灵活。


这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等


微服务的目的是有效的拆分应用，实现敏捷开发和部署 。


如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。


拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。




单一职责原则
  思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的    不必考虑。


服务自治原则
  意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全  可以把它当成一个项目来对待。不必依赖于其它模块。


轻量级通信原则
  首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务  都有足够的独立性，可以不受技术的钳制。


接口明确原则
  由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初  就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。






特点
易于开发和维护 :  只需关心自己模块的逻辑即可
启动较快
局部修改容易部署：哪个模块出现了bug我们只需要解决那个模块的bug就可以了
技术栈不受限：    每个模块都可以使用不同的开发技术，开发模式更灵活
按需伸缩         架构在想扩展某个模块的性能时，不需要考虑其他模块的情况


 缺点
运维要求较高  ：  某个模块出现问题可能造成整个项目出现异常，排除问题往往是困难的，这就对运维人员的要求比较高了
分布式的复杂性 ： 由于分布式本身的复杂性，导致微服务架构也变得复杂起来。
接口调整成本较高：如果某个微服务的接口发生大的变动，那依赖它的微服务都需要大改，所以造成维护的成本将会明显提高。
重复劳动：        微服务的工具类不能共用，所以每个微服务都需要建立一个工具类，所以导致代码重复