华为云做网站,企业app定制开发公司,莱州做网站,深圳政务服务网官网首页为什么80%的码农都做不了架构师#xff1f; 背景 Cloud Native表面看起来比较容易理解#xff0c;但是细思好像又有些模糊不清#xff1a;Cloud Native和Cloud关系是啥#xff1f;它用来解决什么问题#xff1f;它是一个新技术还是一个新的方法#xff1f… 为什么80%的码农都做不了架构师 背景 Cloud Native表面看起来比较容易理解但是细思好像又有些模糊不清Cloud Native和Cloud关系是啥它用来解决什么问题它是一个新技术还是一个新的方法什么样的APP符合“云原生”的呢等等。下面将会一一解读。 Cloud Native介绍 Cloud Native是Matt Stine提出的一个概念它是一个思想的集合包括DevOps、持续交付Continuous Delivery、微服务MicroServices、敏捷基础设施Agile Infrastructure、康威定律Conways Law等以及根据商业能力对公司进行重组。 可以说Cloud Native即包含技术微服务敏捷基础设施也包含管理DevOps持续交付康威定律重组等。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。 Cloud Native的价值 企业采用基于Cloud Native的技术和管理方法可以更好的把业务迁移到云平台从而享受云的高效和按需资源能力。 Cloud Native和传统Cloud的关系 Cloud Native的技术部分是建筑在传统Cloud的三层IaaS、PaaS、SaaS概念之上的 敏捷基础设施对应IaaS部分。微服务则可以对应PaaS和SaaS部分。当然Cloud Native比传统Cloud 多了一些企业管理方法。 备注Cloud Native从技术上更强调敏捷基础设施和微服务的概念这并不意味着它是抛开IaaS、PaaS、SaaS而另起炉灶的。 一篇文章带你了解Cloud Native Cloud Native的五个层面 1 康威定律业务云化推行从某种意义上讲也是一种变革。既然是变革必然会涉及组织的各个层面开发、质量、运维等等都会涉及。康威定律则准确的描述了系统架构和组织的关系组织决定系统架构 一个云系统最终长成什么样子则完全是企业的组织结构决定的是组织内部、组织之间的沟通结构。 如果要想得到一个合理的Cloud架构仅从技术入手是不够的还需要从组织架构入手才真正有效。 一篇文章带你了解Cloud Native 2 DevOps英文Development和Operations的组合是一组过程、方法与系统的统称用 于促进开发应用程序/软件工程、运维和质量保障QA部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到为了按时交付软件产品 和服务开发和运维必须紧密合作。 3 持续交付Continuous Delivery是一系列的开发实践方法用来确保让代码能够快 速、安全的部署到产品环境中它通过将每一次改动都提交到一个模拟产品环境中使用严格的自动化测试确保业务应用和服务能符合预期。因为使用完全的自动 化过程来把每个变更自动的提交到测试环境中所以当业务开发完成时你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。持续交付可以采 用CI持续集成、代码检查、UT单元测试持续部署等方式打通开发、测试、生产的各个环节持续的增量的交付产品。 4 微服务MicroServices微服务首先是一个服务其次该服务的颗粒比较小。微服务可以采用Docker、LXC等技术手段实现。 5 敏捷基础设施Agile Infrastructure提供弹性、按需的计算、存储、网络资源能力。可以通过Openstack、KVM、Ceph、OVS等技术手段实现。 Cloud Native兴起的背后诉求 更快的上线速度细致的故障探测和发现故障时能自动隔离故障时能够自动恢复方便的水平扩容 Cloud Native可以解决上面的诉求 持续交付、DevOps、微服务解决--更快的上线速度微服务解决--细致的故障探测和发现微服务解决--故障时能自动隔离敏捷基础设施、微服务解决--故障时能够自动恢复敏捷基础设施、微服务解决--方便的水平扩容 如何推行Cloud Native 推行Cloud Native可以从如下几方面入手 组织变革根据康威定律如果要达到比较理想的云化效果必须进行组织变革。一个合理的组织架构将会极大提高云化的推行。相信很多公司在决定搞云计算后都大大小小进行了部门合并和组织结构调整。这块水比较深相信很多人有变革的切肤之痛。推行DevOps文化在公司层面推行DevOps文化倡导开放、合作的组织文化打破“部门墙”。推行持续交付联合开发、质量、运维各个环节打通代码提交、代码检查、UT、开发环境部署、staging环境部署、线上环境部署等流水线。建设敏捷基础设施这部分是整个Cloud Native的根基。这部分可以采纳的技术非常多开源的、商用的都比较多。采用微服务架构微服务架构是Cloud Native的一个核心要素。微服务包含几方面的内容 1有支撑微服务的平台。 2有符合微服务平台规范的APP。 3如何引入微服务。 4微服务核心技术点。 微服务的4个方面 1有支撑微服务的平台 支撑微服务的可选技术框架比较多每个公司都可以根据自身情况选择合适的技术框架。比如 KubernetesMesosDockerOpenShift V3Machine Swarm ComposeOpenStack DockerCloud Foundry Lattice 其他技术等等这方面的资料非常多不再细讲。 2有符合微服务平台规范的APP APP要符合12因子Twelve-Factor的规范 基准代码Codebase代码必须纳入配置库统一管理。依赖Dependencies显式的声明对其他服务的依赖比如通过Maven、Bundler、NPM等。配置Config对于不同环境开发/staging/生产等的参数配置是通过环境变量的方式进行注入。后台服务Backing services对于DB、缓存等后台服务是作为附加资源可以独立的Bind/Unbind。编译/发布/运行Build、Release、RunBuild、Release、Run这三个阶段要清晰的定义和分开。无状态进程ProcessesApp的进程是无状态的任何状态信息都存储到Backing servicesDB缓存等。端口绑定Port bindingApp是自包含的所有对外服务通过Port Binding暴露比如通过Http。并发ConcurrencyApp可以水平的Scaling。快速启动终止DisposabilityApp进程可以被安全的、快速的关闭和重启。环境一致性Dev/prod parity尽可能的保持开发、staging、线上环境的一致性。日志Logs把日志作为事件流不管理日志文件通过一个集中的服务由执行环境去收集、聚合、索引、分析日志事件。 3如何引入微服务 直接对原有系统进行微服务改造是比较困难的几乎是不现实的。比较合理的方法是新系统采用微服务开发对老系统进行服务封装系统架构如下所示 一篇文章带你了解Cloud Native Monolith系统对应企业老的系统。 The Anti-Corruption Layer反腐层这层完成对老系统的桥接并阻止老系统的腐烂蔓延。它包含三部分 Facade简化对老系统接口的对接。AdapterRequestResponse 请求协议适配Translator领域模型适配转换微服务模型和老系统模型。新系统微服务新系统开发采用微服务架构。 4微服务核心技术点 主要包含如下几个方面版本控制的分布式配置中心、服务注册和发现、路由和LB、容错、API网关/边缘服务。 4.1版本控制的分布式配置中心 支持配置信息版本化控制可审计安全配置更新不需要重启分布式。这部分可以参考Spring Cloud Config Server、Spring Cloud Bus。 一篇文章带你了解Cloud Native 1用户提交配置更新 2配置server更新 3对APP A发起Refresh更新配置操作 4a发送消息到Bus 4bPull 更新的配置 5aAPP C接收消息 5bPull更新的配置 6其他节点同步更新 4.2服务注册和发现 一篇文章带你了解Cloud Native 这个是传统的服务注册和发现架构图。服务注册方式常见的包括DNS基于ZooKeeper的服务注册方案等等。 备注Consumer和Producer之间一般还有个LB。 4.3路由和LB 一篇文章带你了解Cloud Native 4.4容错 介绍两种模式 A电路熔断器Circuit Breaker 该模式的原理类似于电路熔断器如果电路发生短路熔断器能够主动熔断电路以避免灾难性损失 一篇文章带你了解Cloud Native 正常状态下电路处于关闭状态Closed调用是直接传递给依赖服务的如果调用出错则进入失败计数状态失败计数达到一定阈值后进入熔断状态Open这时的调用总是返回失败累计一段时间以后保护器会尝试进入半熔断状态Half-Open处于Harf-Open状态时调用先被传递给依赖的服务如果成功则重置电路状态为“Closed”否则把电路状态置为“Open”B舱壁Bulkheads该模式像舱壁一样对资源或失败单元进行隔离如果一个船舱破了进水只损失一个船舱其它船舱可以不受影响 。 这种模式比较常见的思路为 采用微服务是首选比如Docker。Docker是进程隔离的单个Docker失效不会影响其他Docker容器。把大的并行处理工作由多个线程池来负荷分担。4.5API网关/边缘服务 一篇文章带你了解Cloud Native API Gateway 对设备侧PC,Mobile等提供简化的单一服务接口它内部聚合后台几十甚至上百微服务。 价值它的主要作用是简化设备侧开发的复杂度减少微服务网络调用数量和网络延迟问题。 VIP Cloud Native实践 参考Cloud Native理念分别介绍VIP实践。 组织层面Cloud的推行是由专门的云平台部门来完成的。云平台拉通开发、QA、运维等各个部门 一起推动电商业务的云化。在推行Cloud过程中我们也碰到了大部分公司都面临的“部门墙”问题。因此目前我们在尝试“项目制”运作方式成立一个项 目组把相关利益责任人拉进来由PMO推动落实。 持续交付目前我们已经开发了CI、CD正在并联合QA Tool工具部线上发布系统打通开发、QA、运维等形成端到端的持续交付流程。持续交付的流程图如下 一篇文章带你了解Cloud Native 敏捷基础设施 一篇文章带你了解Cloud Native 微服务目前唯品会部分业务在尝试采用基于Docker的微服务架构大部分还是采用SOA服务架 构。一个服务的概念对应于我们内部的一个业务域概念目前有1K多的业务域。随着VIP业务的快速发展单个业务域的容量也会快速增长。因此业务域也 在逐步的拆分中业务域数据也会增长几倍。 12因子Twelve-Factor评估由于是基于SOA架构设计大部分可以满足12因子Twelve-Factor的规范。 评估参考下面表格 一篇文章带你了解Cloud Native QA Q如何达到分享老师这种技术深度、广度、理念 A过奖了谢谢。有几点可以和大家分享一下 技术都是慢慢积累过来的你做的久了自然知道的就多些做技术贵在坚持。多和一些大牛学习和交流很重要最直接的就是多向你的直接领导请教多学习每天坚持学习平台很重要有个很好的发展平台可以让你多学习很多内容。 Q唯品会属于康威定律中哪类公司对促进Cloud Native都作了哪些组织结构上的调整 A为了推行Cloud Native我们成立专门的云计算部门。但是为了推行云我们需要和周边各个部门打交道。推行IaaS还好说因为这块基本上是标准化的东东但是在推 行CI、CD时碰到很多问题。CI、CD是和业务密切相关的规范的推行必然会给大家带来额外的工作量。针对这些问题我们是联合多个部门一起搞项目 制运作。 Q在实际使用过程中12因子是定性的还是定量的如何检测 A应该是定性和定量结合更为合适。比如代码统一放入Git库这个是定性。但是代码提交次数代码圈复杂度大小CI成功率等就是定量的。 Q针对移动端的自动化测试你们是怎么做的你们的服务发现是如何做的 A移动端的自动化测试这块了解有限暂时无法答复你。服务发现我们有两种模式DNS传统模式另外一个就是基于自研OSP开放平台的服务注册、服务发现模式。 Q灰度发布采用的什么策略是AB两个集群轮流替换的方式吗 A目前是按批次分批发布的比如50个节点先升级1个再升级20最后升级29个。 Q自动化测试是怎么做的尤其是Web应用的自动化测试采用的什么工具 A我知道的有Test link。 Q这些云上的数据库是如何部署的处理的数据规模有多大事务吞吐量多少扩容这块如何实践的 ADB有专门的部署工具对于规模和事务吞吐量、扩容问题这个比较敏感可以线下专门交流。 Q请问唯品会目前云上用的是什么数据库 AMySQL、MongoDB。 Q请教一下后台数据库是如何分离的比如是不是先从用户微服务中拿用户列表在用用户ID去商品微服务中去拿这个用户的商品列表 A后台DB链接信息一般可以作为环境变量注入App中。 Q在基础设施上您同时使用了虚拟机和Docker请问这两种基础设施承载业务也不同吗 A虚拟机目前是开发测试环境用。Docker后续会直接用在生产环境主要是无状态App甚至缓存。其实VM大部分场景都可以使用Docker代替。 Q在服务注册和发现的图里Consumers应该不会直接连接Producer吧 一般会通过企业治理esg连接 AProducer和Consumer之间一般还有个LB。 Q能把预发布环境理解为集成测试环境吗 A预发布是上线前的一个环节链接的DB都是线上真实环境的。集成测试环境还在预发布环节的前面。 Q作为环境变量到终端DB安全性如何保证难道是每个用户一个DB A一般是后台service链接DB的吧用户是无法接触DB的。 Q那个动态更新配置的服务是需要启动一个守护进程去更新吗 A一般来说client都会安装一个配置agent它来负责从配置server pull配置进行更新。 Q怎么理解版本控制的分布式配置中心主要是配置的哪些信息 A比如Nginx配置端口、vhost等、tomcat配置、DB链接信息、缓存链接信息等等。 Q12因子是否过于严格嘉宾的表格里关于应用无状态也只是部分满足 A12因子主要针对App的它不适用于service层面比如对于dbmc的服务是不适合的。 QGateway实现是使用开源框架kong、loopback还是自己实现 A既可以自己实现比如Java、Nginx也可以采用开源的比如Zuul。 Q必要时进行协议转换比如Http转为AMQP A比如外部是通过http rest请求的拿到这个请求后把参数封装然后以mq的方式发给后台其他服务。 Q微服务一定是无状态的吗 A这个不一定的。 Q能介绍OpenStack 在项目中怎么和Docker等结合使用的吗 A目前我们的CI采用DockerDocker直接跑在VMVM由OpenStack创建上。对于OpenStack底层和Docker如何结合目前还在方案评估中。 转载于:https://my.oschina.net/j4love/blog/3037176
