ygg-w / blog Goto Github PK

redux vs mobx by sorrycc

类（class）是面向对象编程的基础，类的设计是一切 OOP 的起点。构造类的本质就是构造新的类型（types）。C++ 语言的创始人，Bjarne Stroustrup，在他的著作《The C++ Programming Language》中提出了类的七种形式，即应用程序框架（application framework）、抽象类（abstract class）、结点类（node class）、实象类（concrete class）、界面类（interface class）、动作类（action class）、句柄类（handle class）等，本章结合我的感悟来谈在 Lisp 的设计中这七种类的意义和设计方法。

http://zoomq.qiniudn.com/ZQScrapBook/ZqFLOSS/data/20120910171735/

现状（why）

原有consul的控制台功能缺失部分功能

1. 权限管理（对consul的api的访问做权限判断）
2. 服务下线
3. 英文显示不友好等等

目标（what）

控制台改造

Feature List

• 原控制台已有功能
  • 服务列表查看
  • 服务详情查看
  • KV存储
  • 数据中心列表
  • 数据中心详情
  • 节点列表
  • 节点详情
  • acl
• 缺失的功能
  • 下线服务
  • 重启服务等等
• 扩展功能（consul-api不存在的功能）
  • 权限系统

consul-api提供的所有api

方案 (How)

方案-1

ATLAS企业服务

待考证，是否满足上述所有需求

• 购买企业服务，不用自己开发维护
• 扩展困难
• 出问题只能被动的atlas的人来解决
• 这种做法对系统有预设，需要公网环境
• 之后会废弃掉，官方不推荐用。链接

方案-2

基于原本控制台进行改造

• consul控制台启动时，可以指定UI文件目录，可以试着替换原本的UI目录文件，consul的api-server自己不用再开发。
• 控制台的权限可以通过代理服务器来做, 在代理服务器进行代理之前进行权限判断。

方案－3

做法类似方案-2

• 前端和server部分全部自己来处理，自己处理每一个对应的consul api
• 改造程度最大, 开发量也是最大的
• 扩展和维护都由自己来完成

可行性分析

1. atlas在17年3月7号之后，官方便不再推荐使用，故不采纳方案1。

2. 基于原本控制台改造，不修改server部分，这样前后端交互的数据格式会受consul提供的HTTP API的返回数据格式。若要进行进一步改造，可采用方案3.

3. 采纳方案3，由自己开发整个系统。

   • 前端部分

     • 根据需求可以有更加合理的设计

   • 后端部分

     • consul提供了基于多种语言的获取api的client(链接),可以在此基础上开发。java版的consul-client有所有consul提供出的http api。

     • 调用请求顺序:

       当api-server接受到从前端发起到请求时，自己调用consul-client获得相关数据。相当于对consul-client提供出的服务做一次包装。

   • 全部代码由自己维护，可控行更强

结论

采用方案3，基于consul-client做进一步开发。

网关路由Cache策略分析

两种cache策略

两级cache

• 具体做法

cache整个库, 在cache整个库的基础上，做二级缓存，来cache计算结果。

• 优劣

性能最佳，但复杂度过高，维护一致性会非常麻烦.

cache计算结果

• 具体做法

直接cache计算结果。不cache整库。

• 优劣

在cache miss的情况下，性能会有一定影响。当元数据更新之后，不会立即使cache失效，会有一定滞后。但编程复杂度低，容易实现，容易排错。

TradeOff

路由部分配置，属于读多写少。cache 失效的频次会比较低。配置更新的实时性要求没有那么高。
故选择第二种cache策略

缓存更新的套路

1. cache aside pattern
   • 失效：应用先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
   • 命中: 应用程序从cache中取数据，渠道后返回。
   • 更新: 先把数据存到数据库中，成功后，再让缓存失效。
2. Read/Write Through Pattern
   • Read Through: 直接读cache，若未命中，则由缓存服务拉取数据，并更新cache。
   • Write Through:
     直接写cache，由cache自己异步更新DB, 速度快，数据并非强一致性。

cache更新的套路 by 左耳朵耗子

• 场景

  • 订单重复提交时，只真正处理一笔请求，第二笔返回已经处理的结果

• 服务

  • 支付系统对于同一个请求返回同样的结果
  • 如何定义同一个请求
    请求系统的ID＋请求系统的流水号
  • 流程
    • deposit service -> 已有结果 | 没有结果

• 存储

  • 两个系统相互感知的状态放在哪里？
    • 内存
    • redis
    • 数据库

• scale

  • 数据库在设置唯一键约束后，分表之后，相同的key会落在相同的表中。不影响
  • 内存无法避免这种情况
  • redis不用考虑这种情况

• 幂等的两种形式

  • 每次请求返回结果都一样
  • 每次请求，最终结果都一样——接口只要调了就不允许失败

郑均 http://www.cnblogs.com/zhengyun_ustc/archive/2012/11/22/topic6.html

• BDD

  • cucumber
  • 可读性高，我还没搞咋玩
  • 结构有点烂。。。

• JUNIT

  • TDD
  • 简单，用例要自己写，繁琐
  • 核心模块
    • runner
    • rule
    • 核心流程 -- UnitTest生命周期, beforeClass -> before -> Test/FixMethodOrder ->Assert/Assume -> Afte -> AfterClass
    • ClassRule

• quick-check

  • 覆盖率高，没有重复劳动，适合功能比较小的模块，具体怎么写，我再研究研究
  • generator + runner + random
  • 核心流程 -- property + when + from