微服务架构介绍
微服务架构的系统是一个分布式的系统，微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组，每个微服务运行在自己的进程中，并使用轻量级的机制通信。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务，每个微服务代表着一个小的业务能力。这些服务可以使用不同的编程语言，不同数据库，可以满足越来越复杂的业务需求。
微服务优点
1、独立开发：将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。
2、横向扩展：微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。
3、独立扩展：每个组件可以独立地进行扩展。服务间采用HTTP协议通信，在繁忙时期，可以扩展特殊的服务，以支持增加的负载。
4、可重用性：每个组件各自实现一个小的、特定的功能。这意味着它们可以很容易地适用于其他系统、服务或者产品。
微服务缺点
1、开发复杂性增加。对于开发者来说事情会变得更加困难。当开发人员开发一个新功能时，如果该功能依赖其他服务的话，那么开发人员不得不在他们的机器上运行所有服务，或者连接到这些服务。这通常比简单地运行单个程序更加复杂。
2、运营的复杂性增加。对于维护服务的团队来说，潜在的复杂性是一个巨大的挑战。他们管理的服务不是简单的几个，而是数十、数百甚至数千个正在运行的服务。服务数量越多，通信链路就越多，那么出错的可能性就会变大。
3、分布式事务。在需要跨操作交易完整性的情况下，微服务可能会非常痛苦。分布式状态很难处理。
微服务使用场景
1、我们的整个系统目前是所有业务都在一个项目里面，而且不同客户对不同业务模块的需求和取舍都不同，每个业务模块也不能独立出来复用，这样就导致一个项目改来改去N多个版本，管理起来非常麻烦。采用微服务架构，每个业务模块作为一个微服务，根据需求不断完善对应模块的API，这样可以局部更新且不影响其它模块也达到模块复用的目的。在应对不同需求只需调整前端页面和调用不同API，不必复制整个项目。
2、有些业务模块是非常重要且常用的，有些是不常用的，但在整个系统中一旦其中一个不常用模块出现问题可能会导致整个系统不可用。采用微服务，各个服务独立，所以会互不影响。
3、团队中有人对业务A熟悉，有人对业务B熟悉，也有人对业务C熟悉。在这种情况下业务A、B、C都在一个系统中且有关联时往往会耦合性比较大，造成的沟通也比较复杂。除此之外，目前的模式是一个人设计以及分配任务给其他人，这样的问题是一个项目在设计初期一个人难以掌控项目全局，也就难以保证每个业务模块都能理解到位。对于业务模块之间需要通信的，可以采用消息队列来实现，比如RabbitMQ。或者互相调用API来达到目的，具体方案要根据业务情况来确定。不同服务只需要约定好通信方式即可。