微服务架构

软件行业

1. 传统软件行业：
面向企业开发；企业内部员工
2. 互联网软件行业：
面向广大互联网市场；互联网的所有用户

软件架构分类

单体式架构：

将所有的源码都放置在一个总项目中进行开发，管理，部署，运维等等...

特点：

1. 项目迭代不灵活：
单体式结构由于项目代码合在一起，迭代版本越多，项目的代码就越多、越乱；
从中进行部分代码的修改会非常的困难，容易引发未知的风险(影响之前已经上线的项目功能)
2. 项目职责，权限不清：
不同的项目组做的不同模块的开发，需要进行严格的代码保密和权限的划分，以免核心代码泄漏或者错误修改；
3. 项目并发不灵活：
集群的方式进行横向拓展时，每一次拓展都会增加不必要的代码浪费，模块浪费，硬件的消耗

微服务架构：

将项目切分，那么每一个切分出来的都独立成为一个新的项目，每个项目之间按照一定的方式进行通信(分布式)

特点：

1. 项目复杂度低：
分解单体式应用为多个服务的方式，功能不变，应用被拆分成多个可管理的分支或服务。
2. 团队界限明确：
每一个拆分的服务都可以由一个团队专门完成，开发者*选择开发技术，避免了混乱。
3. 拓展灵活：
每一个模块服务都可以独立扩展，可以根据需求，对每一个服务进行满足其需求能力的部署拓展。
（如下图左单体式架构 右微服架构）

微服务架构相关概念

1. 微服务架构将项目拆分之后，项目与项目之间出现关联问题；

一般情况项目通信采用：

• 基于HTTP的RESTful风格的远程服务通信
• 基于RPC的远程服务通信

2. 通信就会产生：一个是提供服务；另一个对服务进行使用

• 提供服务：Provider(提供者)
• 调用服务：Consumer(消费者)

3. RPC服务调用方式：

• 可以在一个项目中像调用本地服务一样去调用其他项目的服务；
• 常见的微服务框架Dubbo和Dubbox；
• 使用@dubboconsumer的service注解。

4. RESTful服务调用方式：

• web请求中将参数封装在url内部(例如：/projectInfo/1；用户id为1的请求信息)；
• 常见的微服务框架Dubbox和SpringCloud。

分布式

• 按照业务功能，将一个完整的项目系统拆分成一个个独立的子系统；
• 每一个子系统被称为服务，这些服务可以部署在不同的服务器上，通过RPC或者RESTful通信。

集群

• 由多个互相独立的，互相连接的计算机构成一个组，单个系统的方式去管理，多个服务器一起做相同的事，提供相同的服务。

另外：

开发环境（development）：

• 开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。(程序员接到需求后，开始写代码，开发，运行程序，看看程序有没有达到预期的功能；)

测试环境（testing）：

• 一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。(程序员开发完成后，交给测试部门全面的测试，看看所实现的功能有没有bug，测试人员会模拟各种操作情况；)

生产环境（production）：

• 是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。(就是线上环境，发布到对外环境上，正式提供给客户使用的环境。)

三个环境也可以说是系统开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。