版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_37958578/article/details/84658114
“微服务架构”在这几年非常的火热，以至于关于微服务架构相关的开源产品被反复的提及（比如：netflix、dubbo），Spring Cloud也因Spring社区的强大知名度和影响力也被广大架构师与开发者备受关注。
一：为什么需要微服务架构？
- 互联网/内联网/网络更加成熟
- 轻量级运行时技术的出现(node.js, WAS Liberty等)
- 新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)
- 新的轻量级协议(RESTful API接口, 轻量级消息机制)
- 简化的基础设施：操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等
- 服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务
- 新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等
- 标准化代码管理：如Github等
二：什么是微服务？
什么是“微服务架构”呢？简单的说，微服务架构就是将一个完整的应用从数据存储开始垂直拆分成多个不同的服务，每个服务都能独立部署、独立维护、独立扩展，服务与服务间通过诸如RESTful API的方式互相调用。这些服务共用一个集中式的管理，服务也可用不同的语音开发，使用不同的数据存储技术。
三：单体架构和微服务架构
单体应用架构顾名思义就是一个包中包含所有的功能的应用程序。单体应用比较容易部署、测试，在项目的初期可以很好的运行，但随着需求的不断增加，单体应用变得越来月臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
优点：
- 易于开发：传统的开发工具和开发流程都对单体架构有很好的支持
- 部署简单：只需要把war文件（或目录层次结构）复制到web服务器即可
- 水平扩展容易：通过在负载均衡器后面运行应用程序的多个副本，很容易做到水平扩展
缺点：
- 复杂性高：随着应用程序需求变多，且复杂，应用程序会变得难以理解和修改
- 部署频率低：随着应用程序越来越大，构建和部署的时间也会增加。全量部署的方式消耗时间长、影响范围大、风险高，这使项目上线部署的频率较低
- 技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积累越多
- 可靠性较低：任何模块中错误都可能导致整个程序执行失败
- 独立扩展能力受限：当不同模块具有不同的资源需求时，单体架构难以独立扩展这些模块
- 阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题，都必须使用相同的开发语音和框架，想要引入新的框架和新技术会非常困难
微服务架构就是将整个应用分解为多个微服务，各个微服务独立运行在自己的进程中，并分别有自己的数据库，微服务之间使用REST或者其他协议通信。
优点：
- 易于开发和维护：每个微服务为独立的业务开发，只关注某个特定的功能，所以业务清晰、代码量较少
- 局部修改容易部署：修改功能后，只需重新部署对应的微服务，无需全部部署，并且不影响其他微服务功能
- 技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈
- 按需伸缩：可根据需求，实现细粒度的扩展
缺点：
- 运维要求较高
- 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题
- 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
- 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复