New architecture graph, new documents. (#2345)

README.md

@@ -31,7 +31,7 @@ The core features are following.
 - Alarm
 
 
-<img src="http://skywalking.apache.org/assets/frame.jpeg"/>
+<img src="http://skywalking.apache.org/assets/frame.jpeg?u=20190311"/>
 
 SkyWalking supports to collect telemetry (traces and metrics) data from multiple sources
 and multiple formats,

docs/en/setup/backend/advanced-deployment.md

@@ -0,0 +1,37 @@
+# Advanced deployment
+OAP servers inter communicate with each other in a cluster environment. 
+In the cluster mode, you could run in different roles.
+- Mixed(default)
+- Receiver
+- Aggregator
+
+In some time, users want to deploy cluster nodes with explicit role. Then could use this.
+
+## Mixed
+Default role, the OAP should take responsibilities of
+1. Receive agent traces or metrics.
+1. Do L1 aggregation
+1. Internal communication(send/receive)
+1. Do L2 aggregation
+1. Persistence
+1. Alarm
+
+## Receiver
+The OAP should take responsibilities of
+1. Receive agent traces or metrics.
+1. Do L1 aggregation
+1. Internal communication(send)
+
+## Aggregator
+The OAP should take responsibilities of
+1. Internal communication(receive)
+1. Do L2 aggregation
+1. Persistence
+1. Alarm
+
+___
+These roles are designed for complex deployment requirements based on security and network policy.
+
+## Kubernetes
+If you are using our native [Kubernetes coordinator](backend-cluster.md#kubernetes), the `labelSelector`
+setting is used for `Aggregator` choose rules. Choose the right OAP deployment based on your requirements.

docs/en/setup/backend/backend-receivers.md

@@ -42,4 +42,21 @@ receiver_zipkin:
     host: 0.0.0.0
     port: 9411
     contextPath: /
-```
+```
+
+## gRPC/HTTP server for receiver
+In default, all gRPC/HTTP services should be served at `core/gRPC` and `core/rest`.
+But the `receiver-sharing-server` module provide a way to make all receivers serving at
+different ip:port, if you set them explicitly. 
+```yaml
+receiver-sharing-server:
+  default:
+    restHost: ${SW_SHARING_SERVER_REST_HOST:0.0.0.0}
+    restPort: ${SW_SHARING_SERVER_REST_PORT:12800}
+    restContextPath: ${SW_SHARING_SERVER_REST_CONTEXT_PATH:/}
+    gRPCHost: ${SW_SHARING_SERVER_GRPC_HOST:0.0.0.0}
+    gRPCPort: ${SW_SHARING_SERVER_GRPC_PORT:11800}
+```
+
+Notice, if you add these settings, make sure they are not as same as core module,
+because gRPC/HTTP servers of core are still used for UI and OAP internal communications.

docs/en/setup/backend/backend-setup.md

@@ -75,6 +75,8 @@ most of backend analysis capabilities based on the scripts. Here is the descript
 which helps you to understand which metric data are in process, also could be used in alarm.
 1. [Alarm](backend-alarm.md). Alarm provides a time-series based check mechanism. You could set alarm 
 rules targeting the analysis oal metric objects.
+1. [Advanced deployment options](advanced-deployment.md). If you want to deploy backend in very large
+scale and support high payload, you may need this. 
 
 ## Telemetry for backend
 OAP backend cluster itself underlying is a distributed streaming process system. For helping the Ops team,