微服务基础了解

目录

特点：

理解：

一、架构演变

1.单体架构：

2.垂直应用架构

3.SOA分布式架构

4.微服务架构

二、远程调用问题

RESTful接口

RPC协议

两者区别与联系

---

微服务可以理解成：是一种架构风格

特点：

把项目拆分成独立可运行的多个服务，每个服务独占一个线程

理解：

一、架构演变

随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，必需一个治理系统确保架构有条不紊的演进。

1.单体架构：

       在软件设计中划分了经典的 3 层模型【控制层，业务逻辑层，数据访问层】，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据。

eg:

比如搭建一个电商系统：客户下订单，商品展示，用户管理，连接同一个数据库。将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

这种架构简单，所有功能在同一个项目中，好维护，小型项目优选，但不利于维护、扩展【技术栈受限】

2.垂直应用架构

       为了避免单体架构上出现的那些问题，开始对应用按照业务做垂直划分【把相同属性的业务功能放到一个大模块中】，把原来的的一个单体架构拆成一堆单体应用，这时候就由原来的单应用变成了多应用部署，这就是垂直架构。

通过垂直拆分，原来的单体项目不至于无限扩大，不同的项目可以使用不同的技术栈，但只是做了共同属性的拆分，拆的不够彻底，需要一个的维护成本，性能扩展只能通过扩展集群结点。

eg：

饿了吗电商平台，官方后台管理一套系统，面向客户PC端一套系统，移动端一套系统。

3.SOA分布式架构

对垂直架构中有冗余的功能模块变成公共服务【包含业务和数据访问层】，独立运行，独立维护。

当不同的控制器调用公共业务时，通过ESB/DUBBO技术实现业务层的调用。

只是对垂直架构的优化，还不具备原子性拆分。

4.微服务架构

是以业务(服务)为中心进行原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。

微服务遵循单一原则。微服务之间采用Restful等轻量协议传输；微服务过多，服务治理成本高，不利于系统维护。

eg：

在电商平台中，用户管理、商品管理、订单管理分别建立用户管理服务、商品管理服务、订单管理服务

二、远程调用问题

       在微服务架构中，通常存在多个服务之间的远程调用的需求。

远程调用通常包含两个部分：序列化和通信协议。

常见的序列化协议包括json、xml、 hession、 protobuf、thrift、text、 bytes等，

目前主流的远程调用技术有基于HTTP的RESTful接口

                                         以及基于TCP的RPC协议。

RESTful接口

RESTFul详细介绍http://t.csdn.cn/zzIXa

  使用Feign实现

RPC协议

  一种进程间通信方式，允许想调用本地服务一样调用远程服务。使用DUBBO实现。

目标：让远程服务调用更简单、透明。

RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式（XML/JSON/二进制）和通信细节。

开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

两者区别与联系

1、 HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如 开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持 的几个协议都包含RESTful。

2、 RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提 供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样 调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。