一：微服务概念及相关组件选型

1.什么是微服务

1）单应用架构

在单体应用架构中，系统将所有的功能包括前端、后端等全部打包在一起部署，所有的代码都写在一起；

优点：

• 项目架构简单，开发成本低
• 项目部署在一个节点上， 维护方便

缺点：

• 代码臃肿庞大，应用启动时间长
• 回归测试周期长，小bug可能需要对所有关键业务进行全面测试
• 应用容错性差，一个细小程序错误可能影响整体应用宕机
• 伸缩困难,若需对应用进行多节点部署时,只能对整个应用进行扩展，造成计算资源浪费
• 开发协作困难，一个大型应用系统，可能几十甚至上百个开发人员，大家都在维护同一套代码，代码版本合并复杂度极高

2）微服务架构

微服务是将单应用划分成一组小的应用服务，服务之间采用轻量级的通信机制互相沟通（REST API或者RPC），每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。

优点（特点）：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

• 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，只要提供Rest的接口即可。

• 自治：自治是说服务间互相独立，互不干扰

  • 团队独立：每个服务都可以是一个独立的开发团队
  • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
  • 前后端分离：采用前后端分离开发，提供统一Rest接口
  • 数据库分离：每个服务都可以使用自己的数据源
  • 部署独立：服务间虽然有调用，但服务重启尽量不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

缺点：

• 运维要求较高
  微服务架构下，每个服务模块出现问题都会造成整个项目运行出现异常，想要知道是哪个服务模块造成的问题相对于单体应用往往是不容易的
• 复杂度更高
  相对于单应用，技术更复杂，技术成本更大。某接口发生大的变动，那么所有依赖它的微服务都要做相应的调整。
• 重复代码
  对于单应用中的抽象工具类可多模块共用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

2.微服务组件选型