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

1.什么是微服务

1）单应用架构

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

优点：

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

缺点：

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

2）微服务架构

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

优点（特点）：

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

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

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

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

缺点：

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

2.微服务组件选型

3.为什么要引入微服务？

实际上，我们有很多方法也可以实现服务间的远程调用通信，例如spring的restTemplate调用，那为啥还要微服务？

部分原因如下：
1.微服务所在的IP地址和端口号硬编码到订单微服务中，会存在非常多的问题
（1）如果被调用方微服务的IP地址或者端口号发生了变化，则被调用方微服务将变 得不可用，需要同步修改调用方微服务中被调用方微服务的IP地址和端口号。
（2）如果系统中提供了多个被调用微服务，则无法实现微服务的负载均衡功能。
（3）如果系统需要支持更高的并发，需要部署更多的微服务，硬编码微服务后续的维护会变得异常复杂。

所以，在微服务开发的过程中，需要引入服务治理功能，实现微服务之间的动态注册与发现