1、Cloud Native演讲人202X-06-0801.02.03.04.目录概念研发流程团队文化架构01概念概念概念起源Cloud Native成熟度模型CloudNative 设计原则概念起源11、WSO2的CTO Paul Frematle在2010年提出22、Netflix的云架构师Adrian Cockcroft在2013年提出33、来自Pivotal的Matt Stine在电子书Migrating to Cloud Native Application Architectures中提出4Cloud Native是一系列架构、研发流程、团队文化的最佳实践集合，以此支撑更快的创新速度、
2、极致的用户体验、稳定可靠的用户服务、高效的研发效率概念 一种能描述应用程序和中间件在云环境中的良好运行状态的架构属性 分布式弹性多租户自服务按需计量和计费增量部署和测试1、WSO2的CTO Paul Frematle在2010年提出2、Netflix的云架构师Adrian Cockcroft在2013年提出Cloud Native的目标ABCD可扩展性高可用性敏捷效率13245共享反脆弱性默认所有依赖都可能失效，在设计阶段就要考虑如何处理这些失效问题管理透明化高信任的组织倡导给基层员工自主决策权不变性服务的实例一旦创建将不能修改，只能通过创建新的节点实现修改关注点分离通过微服务架构实现关注点分
3、离Cloud Native的架构原则2、Netflix的云架构师Adrian Cockcroft在2013年提出应对措施利用AWS实现可扩展性、敏捷和共享01利用猴子工程师（通过有规则的破坏来发现系统脆弱性的工程师）实现反脆弱性03利用CI CD实现敏捷、不变性05利用非标准化的数据实现关注点分离02利用默认开源实现敏捷、共享04利用DevOps实现高信任组织和共享06应对措施2、Netflix的云架构师Adrian Cockcroft在2013年提出u 利用运行自己写的代码实现反脆弱性开发演讲3、来自Pivotal的Matt Stine在电子书Migrating to Cloud Nativ
4、e Application Architectures中提出 在单体架构向CN迁移的过程中，需要文化、组织、技术共同变革。Cloud Native描述为一组最佳实践重点内容01 十二因子02微服务架构要求小团队具有自主决策的权利，避免无论大事小事都要拿到会议上讨论，造成决策瓶颈微服务03 自服务敏捷基础设施04 基于API的协作05 反脆弱性概念Cloud Native成熟度模型ABCD第一级第二级第三级第四级第一级01单体架构或大粒度的拆分应用运行在虚拟化的环境中应用可以通过镜像或脚本自动化部署特征02负载均衡服务、模块化、虚拟化隔离关键技术点03瀑布式开发系统可用性严重依赖运维人员效果第二
5、级特征关键技术点效果第二级特征01020304服务根据业务划分等级微服务架构，服务满足无状态、自治、隔离的条件非核心业务可以实现快速降级不受失败服务的影响，快速隔离关键技术点u微服务框架、CI/CD、自动化测试、分布式配置、监控系统、调用链分析、持续交付流水线第二级第二级效果小团队开发，沟通效率提升对测试人员依赖降低交付周期提升第三级特征关键技术点效果第三级特征可编程基础设施任何时刻业务无中断应用和数据库都能自动伸缩容量、缓存技术中间件作为后端服务提供实现1%->10%->100%的灰度发布流程自动降级第三级特征开发、测试、生产环境统一全球化的业务发布能力，异地多活第三级关键技术点
6、分布式（数据库/存储/缓存/消息队列）全局容错方案混沌测试灰度发布平台全局一致性方案容器关键技术点u资源调度平台第三级第三级效果01020304任意时间发布开发人员专注于业务，架构能力由基础设施承载公共基础服务共享重用DevOps第四级特性01020304系统具有自学习、自诊断、自调整、自恢复能力高度可视化、自动化自动发布（AI选择发布时间）、自动降级、自动回滚AI只能调整系统参数1324高度自动化能力 Serverless概念架构分类强大的公共基础服务 智能化运维 关键技术点第四级效果AIOps/NoOps1瞬间扩展能力2资源利用率极大提升3强大的可用性和一致性4概念CloudNative
7、设计原则1、为失败设计4、标准化2、不变性5、速度优先6、简化设计3、去中心化概念CloudNative 设计原则7、自动化驱动18、演进式设计21、为失败设计重分考虑异常情况所有服务无差异化配置，服务或组件可以自动部署，部署完成后不会发生改变2、不变性越是基础的服务，越需要稳定，越需要简化设计简化运维6、简化设计7、自动化驱动开发人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作。任何重复性工作都应该自动化。当代码提交后，自动化的工具链自动编译、构建、测试代码、验证代码合法性和安全性、是否满足统一标准。开发人员持续优化代码，当满足上线要求的时候，自动化部署到生产环
8、境，这种自动化的方式，能够避免人为失误，以及微服务数量增多后带来的开发和管理的复杂度。02研发流程研发流程研发流程DevOps流水线工具研发流程DevOps流水线工具需求管理代码仓库构建工具包共享仓库持续继承测试DevOps流水线工具u监控研发流程需求管理uJira、KanboardDevOps流水线工具代码仓库ugit、svnDevOps流水线工具构建工具uMaven、GradleDevOps流水线工具包共享仓库uNexusDevOps流水线工具Jenkins持续继承u丰富的插件，如Build Pipeline Plugin、K8s Plugin、JIRA Plugin等测试DevOps流水
9、线工具uJunit-单元测试、Selenium s'linm - UI自动化测试监控uNagios、Zabbix、Prometheus(普罗米修斯)+GrafanaDevOps流水线工具03团队文化团队文化团队文化组织结构环境氛围管理风格组织结构u康威定律团队文化康威定律第一定律：组织沟通方式会通过系统设计表达出来 第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情 一口气吃不成胖子，先搞定能搞定的不指望绝对完美的系统，保障及时恢复的机制复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的第三定律：线型系统和线型组
10、织架构间有潜在的异质同态特性 做独立自治的子系统减少沟通成本按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本第四定律：大的系统组织总是比小系统更倾向于分解 合久必分，分而治之04架构架构架构M.94275.CN315可用性设计微服务架构性能设计426可扩展性设计敏捷基础设施及公共基础服务一致性设计架构未来值得关注的方向架构微服务架构设计原则实施的先决条件划分模式服务间通信设计原则垂直划分原则01持续演进原则02服务自治、接口隔离原则03自动化驱动原则04根据业务领域对服务进行垂直划分。水平划分会导致调用次数增多，性能大幅下降；实现某个功能要跨越更多服务，沟通成本增
11、加 服务间通过接口通信，DB隔离 实施的先决条件拆分前做好解耦 状态外置去触发器、存储过程数据库隔离环境和流程的转变 自动化工具链微服务框架快速申请资源。基础设施即代码，能通过编程的方式管理虚拟机或容器等故障发现与反馈机制组织架构、研发流程转变划分模式基于数据驱动划分基于领域驱动划分单体架构演进为微服务基于数据驱动划分u自下而上的架构设计方法。通过分析需求，确定整体数据结构，根据表之间的关系划分服务。划分模式基于领域驱动划分u自上而下的架构设计方法。通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。划分模式划分模式单体架构演进为微服务比较独立的新业务优先采用微服务架
12、构优先抽象通用服务优先抽象比较容易识别的、边界比较明显的服务优先抽象核心服务优先抽象具有独立属性的服务A/B Test模式逐渐迁移蚕食RPCDubbo作为一个扩展能力极强的分布式服务框架，在实现rpc特性的时候，给传输协议、传输框架和序列化方式提供了多种扩展实现，供开发者根据实际场景进行选择。 传输协议传输框架序列化方式四种序列化协议介绍，性能依次下降常见的RPC序列化协议 跨语言的：Hessian2、JSON、Protostuff，ProtoBufprt'bf，Thrift，Avro阿夫罗，MsgPack等等专门针对Java语言的：Kryo、FST等等Restful方法状态码通过S
13、wagger实现Restful的OpenAPI方法u GET：读取资源，一个或多个u POST：创建资源u DELETE：删除、回收资源u PUT：修改资源，客户端提供修改后的完整资源u PATCH：局部修改资源，客户端只需要提供改变的属性u HEAD：读取资源的头信息，不返回消息主体u OPTIONS：读取对资源的访问权限Restful状态码u1xx：相关信息u2xx：操作成功u3xx：重定向u4xx：客户端错误u5xx：服务器错误RestfulgRPCHttp/2 Http/2对Http/1.x做了大量简化，使得性能大幅度提升Http/2是基于二进制协议，比1.x的文本协议性能更高Http
14、/2使用报头压缩，降低了网络开销Http/2采用了多路复用机制，大幅减少tcp连接的次数Http/2引入服务端推送模式，支持一次请求-多次响应的形式gRPC是Http2和Protobuf的组合架构敏捷基础设施及公共基础服务3152-分布式消息中间件基础设施运维的四个阶段4-分布式任务调度服务4263-分布式缓存 Redis/Memcached1-监控告警服务5-分布式ID基础设施运维的四个阶段1、“人肉”阶段 2、脚本阶段 3、工具阶段 4、敏捷基础设施阶段 基础设施即代码，一个全栈工程师在没有运维人员参与的情况下，申请生产环境的资源，自动化配置，部署应用无需运维人员，全部自动化，通过容器封装
15、环境，开发人员直接将所有软件和依赖封装到容器中，打包成镜像，生产环境直接部署镜像，通过容器实现开发、测试、生产环境的一致。通过容器调度平台管理容器、通过配置文件描述环境，资源利用率更高。1-监控告警服务海 恩 法 则 ： 每 一 起 严 重 的 事 故 背 后 必 然 有 2 9 次 轻 微 事 故和 3 0 0 起 未 遂 先 兆 ， 以 及 1 0 0 0 起 事 故 隐 患 。监 控 数 据 接 收开 源 监 控 实 现 ： P ro m e t h e u s监 控 数 据 采 集监 控 数 据 存 储G r a f a n a1-监控告警服务监控数据采集1-直接上报，通过SDK直连应
16、用，拉取响应的监控数据012-通过日志上报023-通过agent上报，监控系统在镜像中默认安装一个agent，用来获取各个系统的监控指标032-拉模式，业务服务提供API，Monitor根据业务注册的API和配置来拉取数据B1-推模式，Monitor提供API，业务服务主动推送数据给MonitorA1-监控告警服务监控数据接收监控数据存储1-监控告警服务u一般采用时序数据库。InfluxDB/OpenTSDB/Druid/Graphite等开源监控实现：PrometheusuPrometheus是一套开源的监控、报警、时间序列数据库的组合。在2016年加入CNCF（Cloud Native C
17、omputing Foundation）,成为K8S之后的第二个由基金会主持的项目。1-监控告警服务Grafanau一个类似Kibana的东西，也是对后端的数据进行实时展示，大家的日常使用中Kibana是跟着Logstash、ElasticSearch等组件一起使用做日志展示、索引、分析的，造成了一种假象就是Kibana就只有这种用法了，Kibana也可以接入其他数据源的，不过大家最长用的还是展示日志，Grafana是什么呢？该项目你可能没听过，也比较年轻，他一般是和一些时间序列数据库进行配合来展示数据的，例如：Graphite、OpenTSDB、InfluxDB等。1-监控告警服务2-分布式
18、消息中间件Apache开源，历史悠久，功能丰富，适配各种协议，有鉴权机制。缺点性能低，社区越来越不活跃。ActiveMQ基于erlang开发，是采用Erlang语言实现的AMQP协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。RabbitMQ发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。RabbitMQ基于Scala和Java开发，起初是由LinkedIn公司采用Scala语言开发的一个分布式、多分区、多副本且基于zookeeper协调的分布式消息系统，现已捐献给Apache基金会。它是一种高吞吐量的分布式发布订阅消息
19、系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark、Flink等都支持与Kafka集成。 Kafka2-分布式消息中间件RocketMQ 基于java开发（阿里消息中间件），是阿里开源的消息中间件，目前已经捐献个Apache基金会，它是由Java语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点，经历过双11的洗礼，实力不容小觑。3-分布式缓存 Redis/Memcached1、支持的数据结构：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作（最为常用的数据类型主要由
20、五种：String、Hash、List、Set和Sorted Set），M 2、内存使用效率：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memca 3-分布式缓存 Redis/Memcached3、性能对比：两者性能都足够高，吞吐量都接近10万TPS，响应时间都为毫秒级。由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached 4、持久化：Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的
21、持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。 3-分布式缓存 Redis/Memcached5、集群管理：Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。Redis支持多种集群模式。 客户端模式：在客户端做负载均衡（利用Zookeeper或者Etcd等）代理模式：在客户端和服务端之间加一层代理，由代理进行负载均衡，客户端无感知。开源实现有Twemproxy、Codis等SideCar模式：SideCar模式与代理模式很像，不同点在于SideCar模式的P
22、roxy需要和业务服务部署在一起，这样能比代理模式得到更好的性能，并且控制力比客户端模式更好。无中心模式-Redis Cluster：无中心架构绝对的去中心化，元数据分布在所有节点上，不会轻易丢失。所有节点彼此互联（PING-PONG机制），节点之间使用Gossip协议。4-分布式任务调度服务Tbschedule Tbschedule是阿里开源的分布式任务管理服务，采用Zookeeper进行分布管理，代码非常简单，可塑性很好。Elastic-Job 当当开源，在国内应用非常广泛，文档比较丰富，同样采用Zookeeper作为分布式协调服务实现任务调度的。 UUID 开发软件基金会OSF制定的计算
23、标准，用到了以太网卡MAC地址、纳秒级时间、芯片ID码等 Twitter的SnowFlake：SnowFlake是非常优秀的ID生成方案，如果能用SnowFlake的地方绝对不用UUID。 Ticket Server：Flickr采用的一种分布式ID生成方案，利用MySql自增长ID实现。它的设计思路是利用数据库中auto_increment的特性和MySQL特有的REPLACE INF 5-分布式ID架构可用性设计衡量标准01发布机制02容错设计03衡量标准1-基本可用：2个9，99%，年度停机87.6小时2-较高可用：3个9，99.9%，年度停机8.8小时3-高级可用：4个9，99.99%，年度停机53分钟4-极高可用：5个9，99.999%，年度停机5分钟发布机制01影子测试是一种常用的在生产环境中通过日志或TCPCopy将老服务流量复制到新服务，、回放和比对的测试方法影子测试02准备两套一样的生产环境，通过流量切换进行发布和回滚蓝绿部署03小范围尝试灰度发布/金丝雀发布容错设计M.94275.CN0103避免单点、集群设计特性开关服务分级、降级设计02040506超时重试服务隔离、熔断、限流故障演练架构可扩展性设计硬件层面软件层面横向扩展：加机器纵向扩展：增强单机器性能硬件层面感谢聆听感谢聆听
