chapter threee

chapter-2-微服务组成/readme.md

@@ -28,4 +28,20 @@
   * 服务的发布与订阅：也就是消费者如何获得提供者的信息（地址），之间在本地搭建过一套 kafka，需要用到zookeeper去协调这种关系，服务提供者向注册中心发布自己的配置信息，消费者通过监听可以或者服务地址并发送请求，类似与 dns 的原理，主要应用如 etcd、zookeeper；
   * 服务监控：包括数据的收集、处理和展示，比如阿里云的sls，可以通过主动推送日志或 logtail 进行收集，之后通过 sql 进行处理，或者相关的指标，如latency、status等，最后通过 dashboard 进行展示；
   * 故障定位：可以在服务入口生成一个 requestid，并不断传递下去，最后通过这个 requestid 可以将一个请求经过的所有链路串联起来；
-  * 服务治理：模块之间有依赖，如果保证一个模块出问题不影响其他模块，比如熔断、限流等措施；
+  * 服务治理：模块之间有依赖，如果保证一个模块出问题不影响其他模块，比如熔断、限流等措施；
+
+
+### 微服务组件
+  * 服务描述：
+    * restful api：http
+    * xml： pox.xml  
+    * idl文件： protobuf、thrift
+  * 注册中心：也就是上面服务发布与订阅，保证消费者也可以得到服务的地址，并可以及时监听到服务地址的变化状态
+    * 其中服务注册和消费者监听都属于 init 操作, 消费者向服务发送的 invoke 请求同步/异步均可，monitor模块属于 async
+  * 服务框架：
+    * 通信协议： tcp/udp
+    * 数据传输方式：同步/异步
+    * 传输格式：json/pb序列化
+  * 服务监控：同上
+  * 服务追踪：同故障定位
+  * 服务治理   

chapter-3-微服务模块/readme.md

@@ -0,0 +1,106 @@
+## 服务发布和引用
+常见的有3类
+
+| 描述方式 | 应用场景| 特点|
+|------|------------|-----|
+|restful api|跨语言平台，组织内外皆可|较为通用，性能差（底层tcp协议导致）|
+|xml|通常用于java，内部使用|不支持跨语言，如做变更，消费者都需更新xml文件|
+|IDL(grpc,thrift)|跨语言、性能好|修改pb 文件不能做到向前兼容|
+
+
+ 定义proto文件后，可以通过proto生成任意语言的客户端和服务端代码
+ ```
+ // The greeter service definition.
+ service Greeter {
+   // Sends a greeting
+   rpc SayHello (HelloRequest) returns (HelloReply) {}
+   rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}
+
+ }
+
+ // The request message containing the user's name.
+ message HelloRequest {
+   string name = 1;
+ }
+
+ // The response message containing the greetings
+ message HelloReply {
+   string message = 1;
+ }  
+
+ ``` 
+
+
+
+ ## 服务的注册与发现
+
+ 微服务架构通常需要三种角色，服务消费者、服务生产者和注册中心；
+
+ ### 注册中心接口
+ 为了适应服务注册与发现的需求，注册中心需要提供以下接口
+   * 注册服务
+   * 反注册服务
+   * 服务查询
+   * 服务修改
+   * 订阅接口
+   * 变更查询接口
+   * 心跳汇报接口：用于保证服务端存活状态
+
+ ### 注册中心部署
+ 为了避免单点问题，需要做到集群部署，如 zookeeper 多点部署，各 node 通过paxos协议保持一致性原则；
+
+ ### 注册中心数据存储结构
+
+   * 通常为目录结构，每一个目录包含子目录和数据，在 zookeeper 中每一个目录称为一个 znode；
+   * 数据可以做到多版本，比如一个数据的多个版本可以存放在多个节点/某个节点下的子节点；
+
+### health check
+
+客户端定时ping 注册中心，建立一个会话，同时生成一个 sessionid，并不断更新 session timeout,当timeout时间内，注册中心没有收到客户端的请求便认为服务失联，将数据从目录结构中删除；
+
+
+### 服务变更
+异步 watch 机制，当发现注册中心数据更新时，会同步数据更新本地 cache；
+
+### 白名单机制
+
+通常服务方的服务会有多套配置，如测试半，正式版 v1.0/v2.0。。。为了避免用户操作失误，将测试配置上传搭配注册中心，注册中心引入了白名单机制，白名单之外的不可以注册服务；
+
+
+### Q&A: 注册中心和dns有什么区别？
+  * 注册中心属于一级分布式架构，dsn属于多级服务架构
+  * 注册中心具有 health check 机制
+  * 注册中心可以实现负载均衡，通过和多个服务端建立连接池，在调用段通过一定的策略实现负载均衡
+  * dns 手工配置比较麻烦，且更新后有延时
+
+### 解决了上面的初始化问题，该如何进行请求？
+
+单体应用更多是本地调用，微服务化后更多的是远程rpc调用，需要解决4个问题？
+  * 客户端和服务端如何建立网络连接？ 
+
+    * http通信，本质上就是tcp链接，需要三次握手、四次挥手；
+    * socket通信，需要server端进行 bind()、listen 操作，等待客户端connect后进行accept，之后两者进行send/receive操作，最后close结束；
+    * 如何保证cs链接有效，需要两种机制
+      * health check：定时ping，保持心跳
+      * 重试：指数退避，避免服务端因短时间连接数被占满短期内不可用的情况发生
+
+
+  * 服务端如何处理请求？
+
+    同步阻塞/同步非阻塞/异步非阻塞，比如linux里面的select、poll、epoll等server端处理技术；
+
+
+  * 数据传输采用什么协议？
+
+  http/dubbo等，协议需定义好消息头和消息体
+
+  * 如何进行序列化和反序列化？
+    序列化和反序列化就是数据编码和解码的过程，
+    选用什么主要取决三个因素，跨语言支持、压缩比和压缩速率，通常pb的压缩比和压缩速率相比于json都要更好一些
+    * 文本类（json/xml）
+    * 二进制类（thrift，pb）
+
+  序列化可以解决：
+  1).大小端虚，异构系统网络通信时候的大小端序问题，这点由通信底层库实现
+  2).一种协议，在异构语言中进行数据翻译
+  3).压缩优化，提高网络通信能力

chapter-4-monitor/readme.md

@@ -0,0 +1,37 @@
+### 监控系统通常要解决三个问题
+   * 监控的对象是什么？
+   * 监控哪些指标？
+   * 监控维度？
+
+#### 监控指标
+
+  * invokes: 实时的和一段时间的pv；
+  * duration：avg、min，max、p50、p90、p99, 通常关心p99这类高duration的比例
+  * 错误： 4xx、5xx
+
+#### 监控维度
+
+对于一个微服务来说，你必须明确要监控哪些对象、哪些指标，并且还要从不同的维度进行监控，才能掌握微服务的调用情况
+  * 单机维度；防止各个机器不同
+  * 分机房：防止不同机房不同情况
+  * 分时间：
+  * 分模块
+  * 全局的维度
+
+#### 监控模块：
+  * 数据采集：
+    * 本地采集并推送，通过sdk，api之类的方法
+    * 代理收集： 比如sls 的logtail 主动读取本地file
+  * 数据传输
+    * udp
+    * kafka
+  * 数据处理
+
+  计算并存储到db，通过索引数据库（es）、实时数据库
+
+  * dashboard    
+
+
+### 微服务监控
+
+