云计算

云计算(Cloud Computing)是基于互联网的相关服务的增加, 使用和交付模式

• IaaS: Infrastructure as a Service. 最初最基础的云服务, 比如OpenStack, EC2. 关注服务在何处运行
• CaaS: Container as a Service, 通过提供Docker容器和工具链抽象应用的运行时来代替IaaS
• PaaS: Platform as a Service, 平台即服务, 提供更完善的基础能力, 关注应用的打包, 部署, 分发, 监控
• SaaS: Software as a Service, DynamoDB, ElastiCache等等, 直接提供能力和服务
• FaaS: Function as a Service, Amazon Lambda, Azure Functions, Google Cloud Functions

Cloud Native

Cloud Native 是Matt Stine提出的一个概念, 它是一个思想和方法论的集合

• DevOps: 打破开发与运维的隔阂, 能够让应用快速的部署和发布,加快应用迭代
• 持续交付(Continuous Delivery): 利用容器的轻便的特性, 实现容器化, 构建CI/CD流水线
• 微服务(MicroServices): 一种架构风格，将应用程序构建为一系列松散耦合的服务
• 敏捷基础设施(Agile Infrastructure): 提供弹性、按需的计算、存储、网络资源能力
• 康威定律(Conways Law): 设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构

微服务

微服务体系结构是一种架构风格, 将应用程序构建为一系列松散耦合的服务,
实现业务功能, 微服务架构支持大型复杂应用的持续交付/部署

• 基准代码(Codebase): 代码必须纳入配置库统一管理如Git。
• 依赖(Dependencies): 显式的声明对其他服务的依赖, 比如通过Maven、NPM等
• 配置(Config): 对于不同环境(开发/staging/生产等)的参数配置, 是通过环境变量的方式进行注入
• 后台服务(Backing services): 对于DB、缓存等后台服务, 是作为附加资源, 可以独立的Bind/Unbind
• 编译/发布/运行(Build、Release、Run): Build、Release、Run这三个阶段要清晰的定义和分开
• 无状态进程(Processes): 应用的进程是无状态的, 任何状态信息存储到Backing services(DB, 缓存等)
• 端口绑定(Port binding): App是自包含的, 所有对外服务通过PortBinding暴露, 比如通过Http
• 并发(Concurrency): 应用可以水平扩展
• 快速启动终止(Disposability): 应用进程可以被安全的、快速的关闭和重启
• 环境一致性(Dev/prod parity): 尽可能的保持开发、staging、线上环境的一致性
• 快速启动终止(Disposability): 应用进程可以被安全的、快速的关闭和重启
• 日志(Logs): 把日志作为事件流, 不管理日志文件, 通过一个集中的服务, 由执行环境去收集、聚合、索引、分析日志事件

DevOps, 持续交付

DevOps就是解决Dev与Ops隔阂的一种思维方式和文化氛围

• 1. 通过自动化的工具链提高运维效率, 实现CI/CD(持续集成/持续交付).
• 2. 不同角色间沟通与协作问题的流程和方法

容器化

• 轻量, 隔离, 安全, 标准化, 易管理
• 是对应用层和运行时的抽象, 相对VM更适合作为微服务应用的部署架构基础

容器可以作为实现DevOps中持续交付的基础工具之一

容器化更容易实现微服务需要的监控和反馈(告警/日志/度量/链路追踪)

CNCF及Cloud Native生态

Cloud Native Computing Foundation (云原生计算基金会)

是一个厂商中立的基金会, 坚持和整合开源技术来让编排容器作为微服务架构的一部分，
致力于云原生应用推广和普及的一支重要力量

主角: Kubernetes

集群管理的标准

容器和服务编排的规范

云原生操作系统

跨越异构系统的标准层

Kubernetes是Google基于Borg开源的容器编排调度引擎，作为CNCF最重要的组件之一， 它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态， Kubernetes可以帮你将系统自动得达到和维持在这个状态

Docker组织结构和原理浅析

Build, Ship, and Run Any App, Anywhere

Docker 整体架构

Docker Engine

Docker在Linux中的实现原理

• Namespaces: Linux的命名空间机制提供了以下七种不同的命名空间实现不同资源的隔离
• 隔离进程: CLONE_NEWPID, Host上只会有dockerd, docker-containerd进程, 容器内也没有其他进程
• 隔离网络: 每个容器创建一对虚拟网卡, 其中一个加入docker0网桥, 通过NAT实现网络隔离
• 隔离文件: CLONE_NEWNS + chroot 改变根目录挂载点
• 隔离计算资源: CGroups控制内存, CPU, 带宽的分配
• 镜像文件系统: AUFS Advanced UnionFS / overlay2
• 共享: 额外共享目录声明式挂载(默认/var/lib/docker/volumes), 网络也可以有其他共享的模式等等

Docker Image

安装和使用示例

            
              yum install -y yum-utils device-mapper-persistent-data lvm2
              yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
              yum install docker-ce

              systemctl enable docker
              systemctl start docker
              docker run hello-world
            
            
              docker run –name busybox -it –rm busybox
              docker run –name mongodb -d -p 27017:27017 -v /home/mongo_data:/data/db mongo mongod –bind_ip_all
              docker run -it –name node_cmd –rm node /bin/bash
              docker stop -f $(docker ps -a -q)
              docker rm -f $(docker ps -a -q)
              docker rmi nginx

              // dockerhub: https://hub.docker.com/
              docker pull mysql:5.6
              docker build --rm -t name:tag DockerfileDir
              docker exec -it container mkdir /data
              docker diff container
              docker commit --author "xx" --message "xxx" container namespace/image:tag
              docker push namespace/image:tag
            
          

Kubernetes中的资源对象

K8S的作用

Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、 透明的服务注册和服务发现机制、 内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、 可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具， 涵盖开发、部署测试、运维监控等各个环节

为什么需要K8S

• 对底层屏蔽了不同类型计算资源的差异

  • 屏蔽操作系统的差异: 不管是VM, 物理机, 公有云, 都抽象成可调度的节点, 即计算能力
  • 屏蔽网络的差异: Overlay Network, 不管是否在同一个节点, 是否在同一个网段, 都不会影响集群内部网络拓扑
  • 屏蔽存储的差异: 不管是硬盘, 还是网络存储, 还是不同公有云提供商的存储服务, 也不管是什么类型的文件系统, 容器内皆为目录

• 对上层提供了一个标准化的集群管理平台

  • 容器化: 所有的应用运行在隔离的容器中(Pod, StatefulSet, DaemonSet, Job ...)
  • CI/CD流程: 能够与CI系统集成, 提供CD的能力, 并能实现滚动更新, 灰度发布(ConfigMap, Secret, Deployment ...)
  • 服务治理: 提供自动化的水平扩展, 负载均衡, 健康检查/熔断/限流/降级能力(Service, Ingress, Service Mesh ...)
  • 集群管理能力: 提供完善且灵活的集群管理, 集群自我修复(比如Pod漂移)实现高可用(Namespace, Node, LimitRange, RBAC, Federation ...)
  • 可移植能力: 标准化带来的可共享, 可移植的特性极大降低了构建集群的成本(Helm)

这些能力极大简化了: 开发, 测试, 运维监控 (对于开发人员只需关注实现逻辑, 对于测试人员无需考虑环境的差异, 对于运维无需关注特定节点, 只需关注整个集群状态)

微服务化历程中存在的问题分享

• 设计: 架构设计解耦不足 沟通成本和开发成本增加, 加上需求频繁变更, 导致架构腐化
• 开发: 接口文档更新不及时, 上游经常传给下游异常或不规范数据, 开发和调试成本变高
• 测试: CI流程没有自动化单元测试和集成测试, 导致各子服务质量参差不齐, Bug非常多
• 部署: 没有实现CD, 直接shell脚本部署到VM, 也没有无滚动更新和灰度发布机制.
  导致部署耗费人力且易出错, 发布质量较低
• 运维: 虽然已经有调用链监控系统, EFK日志系统, 运维管理系统, 但是没有时间集成.
  导致Dev与Ops存在断层, Dev定位问题不得不进入服务器内部查看日志

总结和思考

• 微服务架构: Not Only Code, 设计与测试至关重要, 汲取领域驱动设计DDD, 测试驱动开发TDD的思维
• 微服务与DevOps相辅相成: 服务拆分的越多, 传统的Dev与Ops协作模式越难管理, 需要高质量自动化的Op流程和更密切的协作, 而Kubernetes就是一个很好的平台
• 少即是多: Less is More. 微服务是用于分治大型应用的复杂度, 不能为了微服务而微服务, 对于单个服务应该Keep it simple and short
• 技术栈日新月异: 关注业界前沿和整体趋势, 扩大技术视野, 持续学习. Stay Hungry, Stay Foolish
• 敏捷开发: 敏捷是通过一个一个小目标快速迭代, 持续交付, 并不是赶进度.
• 技术走在业务前面: 不要等到业务爆发再去解决技术负债, 越到软件开发生命周期的后期, 解决技术债的成本指数级升高

Go语言的现状及生态

• 工程化的语言, 优秀的健壮性, 性能, 先进的并发模型带来的高并发能力
• Cloud Native环境下部分领域的主流编程语言
• 一些基于Golang新兴的开源项目开始赶上或超越Java生态圈
• Consul vs Eureka, Etcd vs zookeeper, NATS vs Kafka/RabbitMQ

服务网格 Service Mesh

• 服务间通信的基础设施层, 服务治理的终极解决方案
• 平台级别的服务发现, 负载均衡, 监控追踪, 限流/熔断/降级

当前主流的 Service Mesh 实现

• Linkerd / istio / Envoy

服务网格的作用

Service Mesh的特点

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

对比Hystrix, Eureka, Ribbon. 同样实现了对服务调用的细粒度控制, 但Sidecar方式部署对应用透明

K8S提供了统一的网关, 配置中心, 服务发现和负载均衡, Service Mesh提供了更强大的服务治理能力...

实现微服务不只是SpringCloud一条路

Serverless, FaaS

• Serverless是一种无服务的架构, 由开发者实现的服务端逻辑运行在无状态的计算容器中, 它是由事件触发，短暂的，完全被第三方管理
• Serverless可以认为是函数即服务 Functions as a Service
• FaaS的思想类似于新的编程范式 Functional Reactive Programming

Cloud Native中的Serverless相关的平台和项目