From 7704dab8dba832e28568446c78e6813e4e3703f2 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Mon, 15 Feb 2016 18:01:42 +0800 Subject: [PATCH] update requirement #57 --- docs/requirement-scenario.md | 25 +++++++++++++----- ...ch.png => scenario-framework-sdk-arch.png} | Bin 2 files changed, 18 insertions(+), 7 deletions(-) rename docs/{TransmittableThreadLocal-arch.png => scenario-framework-sdk-arch.png} (100%) diff --git a/docs/requirement-scenario.md b/docs/requirement-scenario.md index ba2867f97..829632888 100644 --- a/docs/requirement-scenario.md +++ b/docs/requirement-scenario.md @@ -5,9 +5,24 @@ 下面是几个典型场景例子。 -## 应用容器或上层框架跨应用代码给下层SDK传递信息 + + -如在`App Engine`（`PAAS`）上会运行由应用提供商提供的应用（`SAAS`模式）。多个`SAAS`用户购买并使用这个应用（即`SAAS`应用）。`SAAS`应用往往是一个实例为多个`SAAS`用户提供服务。 + +- [1. 分布式跟踪系统](#1-%E5%88%86%E5%B8%83%E5%BC%8F%E8%B7%9F%E8%B8%AA%E7%B3%BB%E7%BB%9F) +- [2. 应用容器或上层框架跨应用代码给下层`SDK`传递信息](#2-%E5%BA%94%E7%94%A8%E5%AE%B9%E5%99%A8%E6%88%96%E4%B8%8A%E5%B1%82%E6%A1%86%E6%9E%B6%E8%B7%A8%E5%BA%94%E7%94%A8%E4%BB%A3%E7%A0%81%E7%BB%99%E4%B8%8B%E5%B1%82sdk%E4%BC%A0%E9%80%92%E4%BF%A1%E6%81%AF) + - [上面场景使用`TTL`的整体构架](#%E4%B8%8A%E9%9D%A2%E5%9C%BA%E6%99%AF%E4%BD%BF%E7%94%A8ttl%E7%9A%84%E6%95%B4%E4%BD%93%E6%9E%84%E6%9E%B6) +- [3. 日志收集记录系统上下文](#3-%E6%97%A5%E5%BF%97%E6%94%B6%E9%9B%86%E8%AE%B0%E5%BD%95%E7%B3%BB%E7%BB%9F%E4%B8%8A%E4%B8%8B%E6%96%87) + + + +## 1. 分布式跟踪系统 + +关于『分布式跟踪系统』可以了解一下`Google`的`Dapper`（介绍的论文：[中文](http://bigbully.github.io/Dapper-translation/)| [英文](http://research.google.com/pubs/pub36356.html)）。分布式跟踪系统作为基础设施，不会限制『使用线程池等会缓存线程的组件』，并期望对业务逻辑尽可能的透明。 + +## 2. 应用容器或上层框架跨应用代码给下层`SDK`传递信息 + +举个具体的业务场景，在`App Engine`（`PAAS`）上会运行由应用提供商提供的应用（`SAAS`模式）。多个`SAAS`用户购买并使用这个应用（即`SAAS`应用）。`SAAS`应用往往是一个实例为多个`SAAS`用户提供服务。 \# 另一种模式是：`SAAS`用户使用完全独立一个`SAAS`应用，包含独立应用实例及其后的数据源（如`DB`、缓存，etc）。 需要避免的`SAAS`应用拿到多个`SAAS`用户的数据。一个解决方法是处理过程关联好一个`SAAS`用户的上下文，在上下文中应用只能处理（读/写）这个`SAAS`用户的数据。请求由`SAAS`用户发起（如从`Web`请求进入`App Engine`），`App Engine`可以知道是从哪个`SAAS`用户，在`Web`请求时在上下文中设置好`SAAS`用户`ID`。应用处理数据（`DB`、`Web`、消息 etc.）是通过`App Engine`提供的服务`SDK`来完成。当应用处理数据时，`SDK`检查数据所属的`SAAS`用户是否和上下文中的`SAAS`用户`ID`一致，如果不一致则拒绝数据的读写。 @@ -16,7 +31,7 @@ ### 上面场景使用`TTL`的整体构架 -构架图 +构架图 构架涉及3个角色：容器、用户应用、`SDK`。 @@ -30,10 +45,6 @@ 整个过程中，上下文的传递 对于 **用户应用代码** 期望是透明的。 -## 2. 分布式跟踪系统 - -关于『分布式跟踪系统』可以了解一下`Google`的`Dapper`（介绍的论文：[中文](http://bigbully.github.io/Dapper-translation/)| [英文](http://research.google.com/pubs/pub36356.html)）。分布式跟踪系统作为基础设施，不会限制『使用线程池等会缓存线程的组件』，并期望对业务逻辑尽可能的透明。所以自己上下文的传递期望 - ## 3. 日志收集记录系统上下文 由于不限制用户应用使用线程池，系统的上下文需要能跨线程的传递，且不影响应用代码。 diff --git a/docs/TransmittableThreadLocal-arch.png b/docs/scenario-framework-sdk-arch.png similarity index 100% rename from docs/TransmittableThreadLocal-arch.png rename to docs/scenario-framework-sdk-arch.png