微服务介绍

单体架构

单体架构就是将所有功能集成到一个项目中进行开发，打包成一个包进行部署。好处是架构简单，各个模块采用统一的架构方案，并且进行部署的时候只需要将一个包进行更新，就能支撑平台所有功能的发布。但是因为所有的代码都写到了同一个包中，各个模块之间的相互调用使其相互之间的功能界限变得模糊，从而渐渐导致耦合度的增高。

分布式架构

由于项目的不断迭代和发展将导致代码的混乱、以及功能界限逐渐模糊的问题，从而导致项目的维护和二次开发变得困难，所以单体架构已经不适合大型项目。

分布式架构表示将一个项目中的各个模块进行拆分，每个模块作为独立的项目进行维护和开发，模块（也就是项目）之间相互调用实现数据的传输，从而解决单体架构所带来的问题。分布式架构有效的降低了项目模块间的耦合度，并且对某个项目的多次部署还能灵活的进行负载均衡，并且因为每个模块都是独立部署的，所以使用什么样的语言或者数据库只要能够完成功能就可以，不再受限于任何技术和框架的要求，从而对于某个模块的升级和扩展对于其他模块来说是没有感知和影响的。

微服务架构特征

微服务架构是分布式架构的一种。

1. 单一职责：每个微服务项目都只负责本服务对应的业务功能，避免重复开发业务。
2. 面向服务：每个服务都必须提供给其他服务可以访问的接口。
3. 服务自治：服务所采用的技术甚至团队也独立管理，各个服务的数据和部署环境也是相互隔离的。
4. 隔离性强：服务之间出现调用，如果被调用方出现问题不能引起调用方的额外异常，所以服务之间要相互隔离，做好容错、降级避免出现级联错误。

最终所有特征所指向的都是高内聚低耦合的思想。

微服务架构方案

SpringCloud与Dubbo

微服务是一种架构思想，具体的落地需要很多技术框架来实现。国内知名的解决方案就是Springcloud和Dubbo。
以上两种微服务实现的效果基本是一样的，都是将模块抽离到单独的服务中，通过通讯的方式进行数据的传输。但是Dubbo并不能说是一个严格的微服务技术实现，而是RPC远程调用框架，更核心的是解决各个服务之间的调用问题，针对其他的微服务必要的组件还需要其他框架或者并未实现。并且在微服务系统中最重要的注册中心组件Dubbo使用了zookeeper或者redis此类并非专业的中间件。
而Springcloud结合了其他厂商开发的专业的各组件，其他厂家可以通过SpringCloud给定的API进行相关的接口开发。阿里巴巴将部分组件实现后，就出现了SpringCloudAlibaba技术栈，表示采用了更多阿里巴巴的组件。

Dubbo的调用协议是特殊的，Nacos不仅支持Feign类http调用方式，同样兼容dubbo协议。

常见的方案

1. 比较常见的：采用Springcloud技术栈，采用Restful风格并使用Feign实现远程调用。
2. 比较先进的：使用SpringcloudAlibaba技术栈，采用Restful风格并使用Feign已实现远程调用。
3. 新老交接的：使用SpriingcloudAlibaba技术栈，采用Dubbo协议并使用Dubbo实现远程调用。
4. 较老版本的：使用Dubbo技术栈，并采用Dubbo协议俄Dubbo实现远程调用。

SpringCloud

相关组件

SpringCloud是国内目前使用最广泛的框架，继承了各种微服务功能组件，基于SpringBoot实现了组件的自动装配，能够让组件能够开箱即用。
各种组件来自各开发厂商和开源团体开发的软件，通过SpringCloud提供的接口标准进行对应开发，通过依赖和安装的方式即可使用。

版本要求

SpringCloud作为依赖引入到项目中时通常使用SpringBoot框架，两个框架有严格的版本对应关系：

本次采用SpringCloud Hoxton.SR10+SptingBoot2.3.x版本。