从 Rails 到 Micro Service

AirJD

没有录音文件

00:00/00:00

加收藏

从 Rails 到 Micro Service

发布者 airjd 简介 Ruby技术大会相关演讲

发布于 1432775217483 浏览 5012 关键词 架构, Ruby

分享到

第1页

从 Rails 到 Micro Service

微服务在e袋洗企业项⺫⽬目架构中的实战应⽤用

关键词: Micro Service, Meta Programming, Dynamic Routing, REST, Zombie Model

第2页

Monolithic System

• ⼀一套程序，解决所有需求 • 依赖全栈式解决⽅方案（ Rails ） • 适合初期探索阶段

第3页

财务

客服

调度

客户

物流

APP

订单客户信息反馈财务物流登录地址服务。。。

第4页

Monolithic System

• 框架臃肿，内存占⽤用⼤大，效率低 • 模型耦合度⾼高，相互影响，不容易进⾏行并⾏行开发 • 单点问题可能导致全局瘫痪 • 可扩展性差，扩展单点服务能⼒力需要所有系统并

⾏行扩展

第5页

财务

客服

调度

客户

物流

APP

订单客户信息反馈财务物流登录地址服务。。。

第6页

财务

客服

调度

客户

物流

负载均衡

APP

订单客户信息反馈财务物流登录地址

服务。。。

订单客户信息反馈财务物流

登录地址服务。。。

订单客户信息反馈财务物流登录地址

服务。。。

第7页

Rails

• 服务端渲染⺴⽹网⻚页 • 提供所有功能，很多功能⽤用不上 • 内存占⽤用⼤大，并发数量低

• 8进程，20线程，⼤大概需要30G的内存

第8页

@robinfan 的服务器相应性能测试

第10页

⺫⽬目前应⽤用的典型场景

• ⼀一个服务型应⽤用需要⽀支撑 • ⼿手机app • 嵌⼊入式H5 应⽤用（微信) • web应⽤用

第11页

⺫⽬目前应⽤用的典型场景

• ⼀一个服务型应⽤用需要⽀支撑 • ⼿手机app - api • 嵌⼊入式H5 应⽤用（微信) - api • web应⽤用 - 服务端渲染或 api

第12页

如果web 端也采⽤用React，Angular 等前端渲染框架的话

全是 API

第13页

如果web 端也采⽤用React，Angular 等前端渲染框架的话

不⽤用服务端渲染⻚页⾯面

第14页

如果web 端也采⽤用React，Angular 等前端渲染框架的话

抛弃全栈，服务器性能将⼤大⼤大增强

第15页

Micro Service 微服务

第16页

Micro Service

• 分布式结构 • 相对独⽴立的服务模块做成⼀一个 Service • Service 对外通过抽象过的接⼝口提供资源 • Service 间通过 Http 或 RPC 协议进⾏行通信 • 独⽴立数据库，独⽴立部署

第17页

财务

客服

调度

客户

物流

APP

订单客户信息反馈财务物流登录地址服务。。。

第18页

财务

客服

调度

客户

物流

APP APP

财务 service

客户反馈

service

调度 service

客服信息

service

地址服务

service

订单 service

第19页

抽象层级

• Api 模型 • 相当于 Controller，通过业务抽象模型提供资源

• 业务抽象模型 • 抽象化的模型，⾃自我闭环完成对外连接 • 看具体需求，有时可以直接由 ORM 模型来充当

• ORM Model • 数据获取 • 服务内模型关系

第20页

API

业务逻辑抽象模型

ORM模型1

ORM模型2

ORM模 ORM模型3 型4

第21页

API

ORM模型1

ORM模型2

ORM模 ORM模型3 型4

第22页

优点 vs 缺点

第23页

Micro Service 的优点vs缺点

• 低耦合，⾼高内聚

• 便于⽔水平扩展，可以⽆无限扩展单点服务能⼒力

• ⾼高可⽤用，⼀一点崩溃，其他点不受影响

• 易于独⽴立测试和发布

VS

• 接⼝口相互调⽤用有延时

• 数据共享困难

• 需要写单独的接⼝口，增加编码量

• 接⼝口更改可能需要客户端和服务端同时发布

• 当有多个维度的时候，资源过滤的接⼝口实现很繁琐（想象4个维度的排列组合）

• 分布式系统，Service 彼此独⽴立，寻找资源成为⼀一个问题

第24页

附加的接⼝口调⽤用

第25页

⾯面对问题，有哪些做的？

第26页

针对数据共享难题

Zombie Model

第27页

怎样组织Service的接⼝口

• Rest ⾯面向对象~ • CRUD

• 针对个体的⽅方法 • Update，Delete， ReadByID • =>实例⽅方法 • host/api/v1/orders/id/232/update…

• 针对群体的接⼝口 • Create, Index, Where, ByType • => 类⽅方法 • host/api/v1/orders/create….

第28页

最终⽤用起来还是对象

第29页

Zombie Model

• 设计⺫⽬目标 • 封装 Service 间资源调⽤用 • 不⽤用写接⼝口请求 • 不⽤用管数据序列化反序列化 • 服务端异常可以同步到客户端，调试和问题追踪变得更简单 • 轻，除⾃自定义⽅方法以外，只⽀支持基础⽅方法，速度快，内存少 • ⽀支持 Active Model 的 Error 返回，保存和更新验证可以直接下穿到服务端 • ⽀支持 Active Record 的链式⽅方法，多维度资源过滤不在纠结 • Zombie::Order.by_type(1).by_user_id(238).by_date(“2015-05-23”) • 动态更新 • 服务间 DIY

第30页

服务端代码量⽐比较

以前：

现在：

第31页

第32页

Zombie Model

• 如何做到？ • 元编程 • 动态定义类 • 动态打开类 • 动态定义⽅方法

第33页

Zombie Model

• 以后会有 • 跨 server 端关系定义 • Server 端动态定义本地⽅方法

第34页

针对资源寻址问题

Dynamic Router

第35页

Dynamic Router

• 设计⺫⽬目的： • 解决分布式资源寻址问题 • ⾼高负载能⼒力 • ⾼高可⽤用性

第36页

Dynamic Router

• ⽤用到的技术 • OpenResty (感谢 @agentzh 章亦春) • Nginx • Lua • Mysql

第37页

功能

• Service 启动的时候，动态注册所有资源以及资源的地址

• 资源地址信息数据库保存，重启的时候⾃自动加载 • 资源路由允许 Proxy Passing 或者 302 两种⽅方式

第38页

服务1

服务2

服务3

第39页

302

Router

服务1

服务2

服务3

第40页

Router

服务3 的接⼝口

服务1

服务2

服务3

第41页

302

Router

服务1

服务2

服务3

第42页

Router

服务1

服务2

服务3

第43页

Dynamic Router

• 性能： • 单核8g内存 • 10000+QPS • ⼏几乎不需要内存 • CPU ~= 100%

第44页

Dynamic Router

• 未来可能⽀支持的功能： • 中央缓存 • 简单的数据访问直接通过 Router来完成 • Service 端动态⽣生成lua代码 • ⾼高级语⾔言驱动低级语⾔言

第45页

关于⼯工作 ~

第46页

为什么会有 Zombie Model， Dynamic Router 这些框架

• 需求驱动技术进步，有实际的需求才有开发相应技术的动⼒力

• 为什么Google发展出了Map Reduce • 实战检验技术结果，没经过实战的技术都不能称之为成熟可靠的技术

• 访问量，瓶颈在哪⾥里，可扩展性和可维护性 • 上升中的公司，业务迅速扩展，开发能⼒力永远不嫌多 • 机会留给有想法的⼈人

• 基础好 • 对技术有感觉 • 期望可以⽤用实战锤炼⾃自⼰己的技术