微服务 Go
微服务
-
微服务：将某个模块拆成单独的服务
缺点：代码量增多 （每个服务间进行交互）开发时间增加 毕竟要考虑怎么拆分 特点： 1.单一职责 2.轻量级通信 ：http rpc 非轻量级：java RMI 3.隔离性：每个服务相互隔离，互不干扰 4.有自己的数据：每个项目可以有自己独立的数据库 互相不影响 5.技术多样性：各种模块可以使用不同的语言 不同的框架去做 例如： 登录注册 java 商品 python 搜索go
微服务诞生背景：
1.联网快速发展 需求变化快 用户数量变化快
2.敏捷开发深入人心，用最小的代价做最快的迭代 频繁修改 测试 上线
3.容器技术成熟，是微服务的技术基础
架构演变历史：
单体架构 ->垂直架构->SOA架构->微服务架构
单体架构：
所有项目集成再一个项目中
项目整个打包 部署到服务器运行
应用和数据库可以分开部署 提高性能
优点：简单开发 开发成本低 架构简单
缺点：项目复杂之后很难扩展和维护,扩展成本高，有瓶颈，技术栈受限，新科技不能使用
垂直架构：
商城项目（单体，有自己的数据库）
物流项目（单体，有自己的数据库）
会造成数据的冗余
项目之间需要处理数据同步，通过数据库同步
比如说用户表
互相之间可以调用 数据库 or 接口
垂直架构师对于大项目的拆分
将整个大项目拆成多个单体项目
优点 ：
小项目的首选，架构同样简单
避免单体架构无线扩大
技术不在受限
缺点：
很多功能放在一个工程中,有一定瓶颈
系统性能扩展要通过集群节点扩展，成本较高
SOA架构：
ESB （Enterprise Service Bus）企业服务总线：
应用需要那块数据访问企业服务总线
是传统中间件技术 与XML、web服务等技术的结合产物
提供网络中最基本的连接中枢，是构筑企业神经网络的必要元素
系统层 和垂直架构一样对项目进行拆分
访问层 ESB 负责调用不同的数据
服务层 抽取系统层冗余的部分 形成数据接口 比如上图用户管理
数据层 不同数据的数据库
优点：
提高系统的可重用性
ESB减少系统接口的耦合性
缺点：
系统与服务界限模糊 不利于系统开发
ESB服务接口协议不固定，不利于系统维护
微服务架构
UI层
网络层
服务层
数据层
特点：
将服务层一个一个的抽取成微服务
遵循单一原则
微服务之间采用一些轻量协议传输数据
优点：
服务拆分力度非常细，利于开发
提高系统的可维护性 那块出问题 维护那块
比EMS更轻量
适用于互联网更新换代快的情况
缺点：
服务过多，服务治理成本高
开发技术要求高
传统访问方式：
微服务访问方式
- APIGetway 解决请求过多时候 接口访问的分配问题
就是将每个模块进行拆分
微服务架构的优势：
- 独立性
- 使用者容易理解
- 技术栈灵活
- 高效团队
微服务架构的不足：
- 额外工作，服务的拆分
- 保证数据一致性
- 增加沟通成本
微服务如何发现
-
客户端发现
- 服务注册 访问注册信息
- 查询注册信息
- 服务调用
- 也就是微服务启动后，将自己IP和端口进行注册，得到提供服务的IP和端口，通过负载均衡访问微服务
-
服务端发现：客户端访问时，不去注册中心了，通过服务发现代理去直接访问
微服务如何部署、更新和扩容
- 微服务部署到docker容器
- 涉及服务编排（容器管理）：K8S，swarm
RPC
- 远程过程调用（Remote Procedure Call，RPC）是一个计算机协议
- 该协议允许运行一台计算机的程序调用另外一台计算机的子程序，而程序员无需额外的为这个交互作用编程
- 如果涉及的软件采用面向对象编程，那么远程过程调用亦可称作远程调用或远程方法调用
流行RPC框架对比
PS： 以上图片源自网络
