分布式架构设计 - 基于Istio+K8s实现微服务可见性

分布式架构设计衍进与学习

1. 更新系列文章 （Kubernetes+Istio） - 2019

基于Kubernetes+Istio实现可观察的微服务

日志（Logs），指标（Metrics）和跟踪（Traces）通常被称为可观察性的三大支柱。

目前看到的最为全面的基于云应用，提供可观测性的现代分布式解决方案，这就是我一直在追寻的，感谢GARY STAFFORD！！My lucky!!

Part1和Part2是基于Json over http

第3篇基于gprc网关反向代理，内部服务基于Grpc协议，对外基于Json和客户端交互

这几篇文章基本涵盖了Golang做微服务的所有主体基础架构，把微服务机座搞定了，很值得把玩！！

中文翻译版本参见：ServiceMesher 公众号

1.1. 相关技术罗列

• Grpc、Json
• Logrus：日志规整收集
• Kiali：服务网格可视化
• Jaeger：分布式链路跟踪
• Prometheus、Grafana：指标收集与告警
• Istio+Envoy：微服务相关（服务注册、服务发现、负载均衡、限流与熔断、指标收集与告警、链路分析）
• K8S：服务编排、资源容器化

1.2. 基于Kubernetes的微服务可观测性与Istio服务网格 - Part1

参见：https://programmaticponderings.com/2019/03/10/kubernetes-based-microservice-observability-with-istio-service-mesh-part-1/

1.3. 基于Kubernetes的微服务可观测性与Istio服务网格 - Part2

参见：https://programmaticponderings.com/2019/03/21/kubernetes-based-microservice-observability-with-istio-service-mesh-part-2/

1.4. 使用Go，gRPC和基于Protobuf的微服务实现Istio可观察性

参见：https://programmaticponderings.com/2019/04/17/istio-observability-with-go-grpc-and-protocol-buffers-based-microservices/

2. 操作系统 - 陈俞、向勇老师《清华大学OS》 2018

操作系统也是软件，比业务系统复杂太多的软件，思考Linux是如何高效而稳定的的运行以及其背后设计的哲学，对系统架构设计有更深层的认证！

2019的GoConf中，滴滴中台设计也提到操作系统一词，重新认识系统架构系统

3. 用Istio和Kubernetes制作微服务 - Ray Tsang 2018

Hear from Ray Tsang on Istio, an open source service mesh framework created by Google, IBM, and Lyft. He’ll explain how the service mesh works, the technology behind it, and what concerns it addresses

参考：https://www.youtube.com/watch?v=goLDtMKrzwE

4. 极客新闻 - 耗子大叔 《左耳听风》 2017

1. 分布式架构冰与火:全栈监控、服务调度、流量与数据调度
2. 分布式系统关键技术：容错、性能、管理
   • 容错/弹力设计 - 系统可用性保障：正确认识故障和弹力设计、服务隔离、异步调用、请求幂等、无状态可伸缩、一致性（事务补偿、重试）、大流量应对（限流、降级、熔断）
     • MTTF（Mean Time To Failure）：多久才故障（SLA, 3个9，折合全年8个小时，4个9，折合全年52分钟，5个9折合全年5分钟）
     • MTTR（Mean Time To Recovery）：平均修复时间
   • 分布式管理/架构设计模式: 分布式锁、配置中心、边车模式、ServerMesh、网关模式、容器化和服务编排、部署升级策略
   • 性能设计: 缓存设计、异步处理、业务分片、索引表、优先队列、边缘计算

5. 如何设计、开发和部署微服务的七篇文章（Nginx Blog) - 2015

服务软件系统开始由单一或者SOA服务向微服务转型方法论

https://www.nginx.com/blog/introduction-to-microservices/

• 微服务简介
• 构建微服务：使用API​​网关
• 构建微服务：微服务架构中的进程间通信
• 微服务架构中的服务发现
• 微服务的事件驱动数据管理
• 选择微服务部署策略
• 将Monolith重构为微服务

5.1. 微服务介绍

1. 单体随业务不断耦合功能越发复杂，维护成本越高，巨大到没有人可以看清单体内部细节，难于扩展，和敏捷脱钩，违背KISS原则
2. 微服务对业务功能模块抽离，每个模块都独立成服务运行在虚拟机或容器上，服务之间通过RESTAPI进行交互
3. 应用程序通过Gateway与后端聚合服务交互，应用程序不能直接访问后端服务，网关负责负载均衡、缓存 、访问控制、API监控（可以基于NGINX实现）
4. 微服务通过模块化做到了功能解耦、数据分区、易于扩展
5. 微服务在数据库方便拆分，每个服务有自己的数据库，而非共享单个数据库
6. 与SOA相比，没有Web服务规范和企业服务总线ESB，微服务更简单
7. 微服务可以独立部署和扩展，并针对应用适配合适的硬件
8. 微服务的目标是充分分解应用，已促进敏捷应用程序的开发和部署

5.2. 微服务挑战

1. 微服务系统是分布式的，同时服务的规模和数量对开发和运维都是一门挑战；
2. 开发需要选择MQ或者RPC进行IPC，还需要做容错处理，比单体应用操作复杂
3. 数据库按模块分区，对业务实体的业务处理是一个挑战，单体共享库的强一致易于实现，但分布式事务受限于Nosql、MQ和CAP定理，开发需要采用BASE最终一致性（Basically Available, SoftState, Eventual Consistency)
4. 其他考虑：
   • RAM当磁盘，磁盘当磁带，磁盘适合顺序存储，随机读取是恶梦（SSD可以解决磁盘寻道时间），数据库也需要充分利用到内存（索引、查询缓存）
   • IMDG（在内存中的数据）比直接RDBMS访问有优势(内存比磁盘文件IO快，并行聚合查询，避免ORM)
5. 微服务的应用编排比单体要复杂（单体几乎没有服务编排，只有模块类或包的调用）
6. 跨多个服务的更改与联动，需要有序的开发和部署（比如一个Story涉及A->B->C，依次更新需要时C、B、A，更多的服务可能带来更大的问题，现在可以通过一些灰度流量的方式平滑发布)
7. 微服务的部署对运维也是一块考验，自动化以及对资源进行虚拟化，按需按量提供硬件资源，基本是微服务的必经之路（K8S+Docker)

6. 大会和资源

1. QConf
2. GOTO Conf

7. 未完