Cloud Native
2020-12-04 10:02:37 2 举报AI智能生成
CloudNative云原生概念全解析
作者其他创作
大纲/内容
架构
微服务架构
设计原则
垂直划分原则
根据业务领域对服务进行垂直划分。水平划分会导致调用次数增多，性能大幅下降；实现某个功能要跨越更多服务，沟通成本增加
持续演进原则
服务自治、接口隔离原则
服务间通过接口通信，DB隔离
自动化驱动原则
实施的先决条件
环境和流程的转变
自动化工具链
微服务框架
快速申请资源。基础设施即代码，能通过编程的方式管理虚拟机或容器等
故障发现与反馈机制
组织架构、研发流程转变
拆分前做好解耦
状态外置
去触发器、存储过程
数据库隔离
划分模式
基于数据驱动划分
自下而上的架构设计方法。通过分析需求，确定整体数据结构，根据表之间的关系划分服务。
基于领域驱动划分
自上而下的架构设计方法。通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。
单体架构演进为微服务
比较独立的新业务优先采用微服务架构
优先抽象通用服务
优先抽象比较容易识别的、边界比较明显的服务
优先抽象核心服务
优先抽象具有独立属性的服务
A/B Test模式逐渐迁移蚕食
服务间通信
RPC
常见的RPC序列化协议
跨语言的：Hessian2、JSON、Protostuff，ProtoBuf[prəʊtə'bʌf]，Thrift，Avro[阿夫罗]，MsgPack等等
专门针对Java语言的：Kryo、FST等等
Dubbo作为一个扩展能力极强的分布式服务框架，在实现rpc特性的时候，给传输协议、传输框架和序列化方式提供了多种扩展实现，供开发者根据实际场景进行选择。
传输协议
RMI、Dubbo、Hessian['heʃən]、WebService、Http等，其中Dubbo和RMI协议基于TCP实现，Hessian和WebService基于HTTP实现。
传输框架
Netty、Mina['mainə]、grizzly以及基于servlet等方式。
序列化方式
Hessian2、dubbo、JSON（ fastjson 实现）、JAVA、SOAP、kryo和fst 等。
四种序列化协议介绍，性能依次下降
1-dubbo序列化：阿里尚未开发成熟的高效java序列化实现，阿里不建议在生产环境使用它
2-hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的hessian lite，它是dubbo RPC默认启用的序列化方式
3-json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。
4-java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。
Restful
方法
GET：读取资源，一个或多个
POST：创建资源
DELETE：删除、回收资源
PUT：修改资源，客户端提供修改后的完整资源
PATCH：局部修改资源，客户端只需要提供改变的属性
HEAD：读取资源的头信息，不返回消息主体
OPTIONS：读取对资源的访问权限
状态码
1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误
通过Swagger实现Restful的OpenAPI
gRPC
Http/2
Http/2对Http/1.x做了大量简化，使得性能大幅度提升
Http/2是基于二进制协议，比1.x的文本协议性能更高
Http/2使用报头压缩，降低了网络开销
Http/2采用了多路复用机制，大幅减少tcp连接的次数
Http/2引入服务端推送模式，支持一次请求-多次响应的形式
gRPC是Http2和Protobuf的组合
敏捷基础设施及公共基础服务
基础设施运维的四个阶段
1、“人肉”阶段
2、脚本阶段
3、工具阶段
4、敏捷基础设施阶段
基础设施即代码，一个全栈工程师在没有运维人员参与的情况下，申请生产环境的资源，自动化配置，部署应用
无需运维人员，全部自动化，通过容器封装环境，开发人员直接将所有软件和依赖封装到容器中，打包成镜像，生产环境直接部署镜像，通过容器实现开发、测试、生产环境的一致。通过容器调度平台管理容器、通过配置文件描述环境，资源利用率更高。
1-监控告警服务
海恩法则：每一起严重的事故背后必然有29次轻微事故和300起未遂先兆，以及1000起事故隐患。
监控数据采集
1-直接上报，通过SDK直连应用，拉取响应的监控数据
2-通过日志上报
3-通过agent上报，监控系统在镜像中默认安装一个agent，用来获取各个系统的监控指标
监控数据接收
1-推模式，Monitor提供API，业务服务主动推送数据给Monitor
2-拉模式，业务服务提供API，Monitor根据业务注册的API和配置来拉取数据
监控数据存储
一般采用时序数据库。InfluxDB/OpenTSDB/Druid/Graphite等
开源监控实现：Prometheus
Grafana
一个类似Kibana的东西，也是对后端的数据进行实时展示，大家的日常使用中Kibana是跟着Logstash、ElasticSearch等组件一起使用做日志展示、索引、分析的，造成了一种假象就是Kibana就只有这种用法了，Kibana也可以接入其他数据源的，不过大家最长用的还是展示日志，Grafana是什么呢？该项目你可能没听过，也比较年轻，他一般是和一些时间序列数据库进行配合来展示数据的，例如：Graphite、OpenTSDB、InfluxDB等。
2-分布式消息中间件
ActiveMQ
Apache开源，历史悠久，功能丰富，适配各种协议，有鉴权机制。缺点性能低，社区越来越不活跃。
RabbitMQ
基于erlang开发，是采用Erlang语言实现的AMQP协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。RabbitMQ发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。
Kafka
基于Scala和Java开发，起初是由LinkedIn公司采用Scala语言开发的一个分布式、多分区、多副本且基于zookeeper协调的分布式消息系统，现已捐献给Apache基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark、Flink等都支持与Kafka集成。
RocketMQ
基于java开发（阿里消息中间件），是阿里开源的消息中间件，目前已经捐献个Apache基金会，它是由Java语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点，经历过双11的洗礼，实力不容小觑。
3-分布式缓存 Redis/Memcached
1、支持的数据结构：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作（最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set），Memcached只支持KV结构，对于复杂结构需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。
2、内存使用效率：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
3、性能对比：两者性能都足够高，吞吐量都接近10万TPS，响应时间都为毫秒级。由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。
4、持久化：Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。
5、集群管理：Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。Redis支持多种集群模式。
客户端模式：在客户端做负载均衡（利用Zookeeper或者Etcd等）
代理模式：在客户端和服务端之间加一层代理，由代理进行负载均衡，客户端无感知。开源实现有Twemproxy、Codis等
SideCar模式：SideCar模式与代理模式很像，不同点在于SideCar模式的Proxy需要和业务服务部署在一起，这样能比代理模式得到更好的性能，并且控制力比客户端模式更好。
无中心模式-Redis Cluster：无中心架构绝对的去中心化，元数据分布在所有节点上，不会轻易丢失。所有节点彼此互联（PING-PONG机制），节点之间使用Gossip协议。
4-分布式任务调度服务
Tbschedule
Tbschedule是阿里开源的分布式任务管理服务，采用Zookeeper进行分布管理，代码非常简单，可塑性很好。
Elastic-Job
当当开源，在国内应用非常广泛，文档比较丰富，同样采用Zookeeper作为分布式协调服务实现任务调度的。
5-分布式ID
UUID
开发软件基金会OSF制定的计算标准，用到了以太网卡MAC地址、纳秒级时间、芯片ID码等
Twitter的SnowFlake：SnowFlake是非常优秀的ID生成方案，如果能用SnowFlake的地方绝对不用UUID。
Ticket Server：Flickr采用的一种分布式ID生成方案，利用MySql自增长ID实现。它的设计思路是利用数据库中auto_increment的特性和MySQL特有的REPLACE INFO命令来实现，可以利用多台MySQL实现高扩展性和高可用性。
可用性设计
衡量标准
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分钟
发布机制
影子测试
影子测试是一种常用的在生产环境中通过日志或TCPCopy将老服务流量复制到新服务，、回放和比对的测试方法
蓝绿部署
准备两套一样的生产环境，通过流量切换进行发布和回滚
灰度发布/金丝雀发布
小范围尝试
容错设计
避免单点、集群设计
特性开关
服务分级、降级设计
超时重试
服务隔离、熔断、限流
故障演练
可扩展性设计
硬件层面
横向扩展：加机器
纵向扩展：增强单机器性能
软件层面
AKF扩展立方体
X轴：无差别的克隆服务和数据
如应用负载
数据库读写分离，主库写，备库自由扩容读
数据异构、数据聚合
Y轴：面向服务和资源的分割
服务拆分（SOA、微服务）
Z轴：基于客户或请求者分割工作
面向查找分割，如将不同区域用户哈希到不同的服务
算法分片
分库分表
业务维度
物理逻辑维度
性能设计
性能指标
响应时间
吞吐量
负载敏感度
响应时间随其他因素的衰减速度
可伸缩性
系统增加资源对性能的影响。例如要使吞吐量增加一倍，需要增加多少服务器。
通过压测找到吞吐量和响应时间的平衡点
当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。
系统资源和TPS随着并发数的变化
并发用户访问响应时间曲线
性能测试结果报告
一致性设计
http://miclee.site/2019/01/11/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
未来值得关注的方向
Serverless
Service Mesh
【服务网格】是用于处理服务间通信的专用基础架构层。Cloud Native有着复杂的服务拓扑，Service Mesh负责可靠的传递请求，帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制。业务的所有流量都转发到Service Mesh代理服务中，不仅如此Service Mesh还承担了服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速、上报日志、监控报警等微服务框架的所有功能！
云原生的技术版图逐渐丰富，包括Kubernetes在内的现有容器技术解决了应用快速部署和上线等问题，但部署之后的应用运行问题，类似于灰度发布、流量治理与健康管理等还没有得到很好解决，Service Mesh应运而生。
Cloud Native
概念
起源
1、WSO2的CTO Paul Frematle在2010年提出
一种能描述应用程序和中间件在云环境中的良好运行状态的架构
属性
分布式
弹性
多租户
自服务
按需计量和计费
增量部署和测试
2、Netflix的云架构师Adrian Cockcroft在2013年提出
Cloud Native的目标
可扩展性
高可用性
敏捷
效率
Cloud Native的架构原则
不变性
服务的实例一旦创建将不能修改，只能通过创建新的节点实现修改
关注点分离
通过微服务架构实现关注点分离
反脆弱性
默认所有依赖都可能失效，在设计阶段就要考虑如何处理这些失效问题
高信任的组织
倡导给基层员工自主决策权
共享
管理透明化
应对措施
利用AWS实现可扩展性、敏捷和共享
利用非标准化的数据实现关注点分离
利用猴子工程师（通过有规则的破坏来发现系统脆弱性的工程师）实现反脆弱性
利用默认开源实现敏捷、共享
利用CI CD实现敏捷、不变性
利用DevOps实现高信任组织和共享
利用运行自己写的代码实现反脆弱性开发演讲
3、来自Pivotal的Matt Stine在电子书Migrating to Cloud Native Application Architectures中提出
在单体架构向CN迁移的过程中，需要文化、组织、技术共同变革。Cloud Native描述为一组最佳实践
重点内容
十二因子
微服务
微服务架构要求小团队具有自主决策的权利，避免无论大事小事都要拿到会议上讨论，造成决策瓶颈
自服务敏捷基础设施
基于API的协作
Cloud Native是一系列架构、研发流程、团队文化的最佳实践集合，以此支撑更快的创新速度、极致的用户体验、稳定可靠的用户服务、高效的研发效率
Cloud Native成熟度模型
第一级
特征
单体架构或大粒度的拆分
应用运行在虚拟化的环境中
应用可以通过镜像或脚本自动化部署
关键技术点
负载均衡服务、模块化、虚拟化隔离
效果
瀑布式开发
系统可用性严重依赖运维人员
第二级
服务根据业务划分等级
微服务架构，服务满足无状态、自治、隔离的条件
非核心业务可以实现快速降级
不受失败服务的影响，快速隔离
微服务框架、CI/CD、自动化测试、分布式配置、监控系统、调用链分析、持续交付流水线
交付周期提升
小团队开发，沟通效率提升
对测试人员依赖降低
第三级
可编程基础设施
中间件作为后端服务提供
任何时刻业务无中断
实现1%->10%->100%的灰度发布流程
应用和数据库都能自动伸缩容量、缓存技术
自动降级
开发、测试、生产环境统一
全球化的业务发布能力，异地多活
分布式（数据库/存储/缓存/消息队列）
灰度发布平台
全局容错方案
全局一致性方案
混沌测试
容器
资源调度平台
任意时间发布
开发人员专注于业务，架构能力由基础设施承载
公共基础服务共享重用
DevOps
第四级
特性
系统具有自学习、自诊断、自调整、自恢复能力
高度可视化、自动化
自动发布（AI选择发布时间）、自动降级、自动回滚
AI只能调整系统参数
强大的公共基础服务
智能化运维
高度自动化能力
架构分类
BaaS
FaaS
AIOps/NoOps
瞬间扩展能力
资源利用率极大提升
强大的可用性和一致性
CloudNative 设计原则
1、为失败设计
重分考虑异常情况
2、不变性
所有服务无差异化配置，服务或组件可以自动部署，部署完成后不会发生改变
3、去中心化
4、标准化
5、速度优先
6、简化设计
越是基础的服务，越需要稳定，越需要简化设计简化运维
7、自动化驱动
开发人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作。任何重复性工作都应该自动化。当代码提交后，自动化的工具链自动编译、构建、测试代码、验证代码合法性和安全性、是否满足统一标准。开发人员持续优化代码，当满足上线要求的时候，自动化部署到生产环境，这种自动化的方式，能够避免人为失误，以及微服务数量增多后带来的开发和管理的复杂度。
8、演进式设计
研发流程
DevOps流水线工具
需求管理
Jira、Kanboard
代码仓库
git、svn
构建工具
Maven、Gradle
包共享仓库
Nexus
持续继承
Jenkins
丰富的插件，如Build Pipeline Plugin、K8s Plugin、JIRA Plugin等
测试
Junit-单元测试、Selenium [sə'linɪəm] - UI自动化测试
监控
Nagios、Zabbix、Prometheus(普罗米修斯)+Grafana
团队文化
组织结构
康威定律
第一定律：组织沟通方式会通过系统设计表达出来
第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情
一口气吃不成胖子，先搞定能搞定的
不指望绝对完美的系统，保障及时恢复的机制
复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的
第三定律：线型系统和线型组织架构间有潜在的异质同态特性
做独立自治的子系统减少沟通成本
按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本
第四定律：大的系统组织总是比小系统更倾向于分解
合久必分，分而治之
环境氛围
管理风格
0 条评论
回复 删除
下一页
