只做瓶子包装设计的创意网站,做网站最多的行业,做网站公司郑州,用源码做自己的网站所谓云原生#xff0c;它不是一个产品#xff0c;而是一套技术体系和一套方法论#xff0c;而数字化转型是思想先行#xff0c;从内到外的整体变革。更确切地说#xff0c;它是一种文化#xff0c;更是一种潮流#xff0c;是云计算的一个必然导向。随着虚拟化技术的成熟… 所谓云原生它不是一个产品而是一套技术体系和一套方法论而数字化转型是思想先行从内到外的整体变革。更确切地说它是一种文化更是一种潮流是云计算的一个必然导向。随着虚拟化技术的成熟和分布式架构的普及用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。在容器技术、可持续交付、编排系统等开源社区的推动下以及微服务等开发理念的带动下应用上云已经是不可逆转的趋势。随着云化技术的不断进展云原生的概念也应运而生。云原生概念的诞生云原生Cloud Native的概念由来自Pivotal的MattStine于2013年首次提出被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合并得到了社区的不断完善内容非常多包括DevOps、持续交付Continuous Delivery、微服务MicroServices、敏捷基础设施Agile Infrastructure和12要素The Twelve-Factor App等几大主题不但包括根据业务能力对公司进行文化、组织架构的重组与建设也包括方法论与原则还有具体的操作工具。采用基于云原生的技术和管理方法可以更好地把业务生于“云”或迁移到云平台从而享受“云”的高效和持续的服务能力。The Twelve-Factor App顾名思义云原生是面向“云”而设计的应用因此技术部分依赖于传统云计算的3层概念基础设施即服务IaaS、平台即服务PaaS和软件即服务SaaS例如敏捷的不可变基础设施交付类似于IaaS用来提供计算网络存储等基础资源这些资源是可编程且不可变的直接通过API可以对外提供服务有些应用通过PaaS服务本来就能组合成不同的业务能力不一定需要从头开始建设还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务即SaaS能力用户直接面对的就是原生的应用。云原生并不是一个产品最近讨论云原生应用越来越多。关于云原生应用简单地说就是大多数传统的应用不做任何改动都是可以在云平台运行起来只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式仅仅是把虚拟机当物理机一样使用不能够真正利用起来云平台的能力。云并非把原先在物理服务器上跑的东西放到虚拟机里跑真正的云化不仅是基础设施和平台的事情应用也要做出改变改变传统的做法实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多如容器技术、微服务、可持续交付、DevOps等。而云原生应用最大的特点就是可以迅速部署新业务。在企业里提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险因为犯错及改错也需要花费同样的时间成本竞争优势就会由此产生。所以云原生不是一个产品而是一套技术体系和一套方法论而数字化转型是思想先行从内到外的整体变革。更确切地说它是一种文化更是一种潮流是云计算的一个必然导向。意义在于让云成为云化战略成功的基石而不是障碍。它可以根据商业能力对公司进行重组的能力既包含技术、也包含管理可以说是一系列云技术和企业管理方法的集合通过实践及与其他工具相结合更好地帮助用户实现数字化转型。云原生计算基金会CNCFCNCF即云原生计算基金会2015年由谷歌牵头成立基金会成员目前已有一百多企业与机构包括亚马逊、微软、思科等巨头。目前CNCF所托管的应用已达14个下图为其公布的Cloud Native Landscape给出了云原生生态的参考体系。Cloud Native Landscape新版CNCF(云原生计算基金会)认为云原生系统需包含的属性容器化封装以容器为基础提高整体开发水平形成代码和组件重用简化云原生应用程序的维护。在容器中运行应用程序和进程并作为应用程序部署的独立单元实现高水平资源隔离。自动化管理统一调度和管理中心从根本上提高系统和资源利用率同时降低运维成本。面向微服务通过松耦合方式提升应用程序的整体敏捷性和可维护性。正因为如此你可以专注于创新解决业务问题而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。云原生的四要素持续交付、DevOps、微服务、容器从云原生的概念中我们总是能看到持续交付、DevOps、微服务、容器等技术的出现那么它们到底是什么这里引用Pivotal台湾云计算资深架构师的部分观点为大家逐一揭开他们的神秘面纱01持续交付——缩小开发者认知灵活开发方向首先是持续交付什么样的时候客户要求持续交付敏捷开发要求持续交付因为敏捷开发要求随时有一个版本可以上到大群环境所以要持续交付。而换句话说持续交付就是不误时开发。举一个例子有些公司非常喜欢谈需求谈很久可是开发只剩1/3时间就开发完成然后交付再上线运营。这就会碰到一个问题就是你开始谈需求到最后交付产品的时间短则三月长则半年这中间市场已经变化了需求也随之变化了。因此市场上出现了新的想法即是不是能够小步快跑把交付的周期缩短一点我可以实现快速交付每次交付都可以重新确认方向这样尽量避免与未来期待的落差。用小步快跑的方式打破瀑布式开发流程那么问题来了持续交付对于开发的人谈的需求、开发的方式有改变那它对于开发有影响吗如果说公司的开发团队一天可以交付五次那研发团队要帮忙部署一次吗现在公司大部分部署都是研发团队帮忙部署应用的研发团队部署五次要改版五次就需要部署一次这是无法实现的。而且每次部署的时候都要面对停机而实际公司的应用经不起一天停机五次部署在互联网的思维之下零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面第一版还在线上服务第二版先做封测封测完成后让外面的流量进来一些看log是不是开发人员要的确认后再把全部的流量导到新的版本上。图蓝绿(Blue-Green) 部署但“蓝绿部署”在系统过多过复杂的情况下在传统架构上实现非常困难所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此持续交付的优势在于它可以缩小开发者认知重新确认开发方向。02微服务——内聚更强更加敏捷第二部分是微服务。微服务是什么有客户表示提供商出产品客户把应用全部放上去结果就是一个微服务。这种认知是错误的因为微服务是一个架构的改变。那么微服务是怎么做的呢它所面临的最大挑战是什么是切割。那么如何切割呢其实这件事情早在1968年康威就提出了——康威定律系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法我认为拿来做微服务的切割非常适用。Going Agile - Breaking the monolithConways Law and Microservices这样按照组织架构划分的优势在于1.内聚更强所有遵循同一种业务准则的人内聚在一起就容易解决问题。2.服务解耦变更容易更加敏捷。当做到解耦合的时候要变更就容易。所以微服务应该是切分成这个样子由上而下来切根据Function来切。另外一个划分微服务的技巧可以运用领域驱动设计(Domain Driven Design)的理论而领域驱动设计亦可算是面向物件的一种设计思维聚合可以让微服务划分更有依据也让未來的系統变更具有弹性。值得一提的是领域驱动设计也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段相当容易也常见但在微服务架构中如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计是目前最好的解決办法。那么在什么情况下需要微服务我认为有三个标准1.有HAHigh Available的需求需要微服务。2.有性能调校的需求例如图片的呈现或者搜寻需要微服务。3.经常变更的需要微服务。实际上微服务需要关注的源代码范围比较小使得各个服务解耦、变更容易内聚更强因为都会集中在服务里。另外它更容易单独改版因为微服务之间是用RESTful间接起来的用RESTful只要API的界面不改原则上则不会错也更敏捷。但微服务也会留下一些问题例如App团队如何分工环境怎么配合如何实现自动化部署?03容器技术——使资源调度、微服务更容易再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程与任何其他进程无异。那么为什么容器如此受欢迎呢原因在于这个进程被隔离和限制的方式。这种方式很特殊可简化开发和运维。其实1979年就有容器技术很多人会以为说Docker是不是等于容器其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念cgroup、namespaces和filesystems在独立的区域运行。容器的神奇之处在于将这些技术融为一体以实现最大的便利性。VMware之前的技术专家在2011年发展出一个技术把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有而且它第一版是用SLC的技术去做的。后来陆续一路成长使得为服务的实现更容易了。从 Infra 角度来看技术演进从上面这个表中可以看出从左边开始IaaS虚拟化技术有了之后刚刚提到的所谓第三代平台这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进对于客户的负担越到后面越小而对于开发人员的想象力则愈发抽象。大家一定会遇到下列这些计算一个是所谓的单体应用或者翻译成巨石应用。此外你们一定会有一些批次的管理另外就是所谓的数据库的部分开始可能会有容器技术像K8S、Dock。Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器谷歌建立了Kubernetes。它提供了一些强大的功能例如容器之间的负载均衡重启失败的容器以及编排容器使用的存储。容器生态图 /作者Jimmy Song容器为云原生应用程序增加了更多优势。使用容器你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上而无需重新配置环境这样就实现了强大的可移植性。04DevOps——以终为始运维合一最后让我们走向DevOps它不是一种工具DevOps其实要谈的是运维合一。DevOps如果从字面上来理解只是Dev开发人员Ops运维人员实际上它是一组过程、方法与系统的统称其概念从2009年首次提出发展到现在内容也非常丰富有理论也有实践包括组织文化、自动化、精益、反馈和分享等不同方面。首先组织架构、企业文化与理念等需要自上而下设计用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合简单而言组织形式类似于系统分层设计。其次自动化是指所有的操作都不需要人工参与全部依赖系统自动完成比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次DevOps的出现是由于软件行业日益清晰地认识到为了按时交付软件产品和服务开发部门和运维部门必须紧密合作。总之DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理从而更快、更频繁地交付更稳定的软件。在内部沟通上你可以想象DevOps是一个敏捷思維是一个沟通的文化。当运营和研发有良好的沟通效率才可以有更大的生产力。如果你的自动化程度够高可以自主可控工作负担降低DevOps能够带来更好的工作文化、更高的工作效率。总结综上所述云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分需要以全局地眼光看待问题脱离任何一个元素对于企业来说都是“管中窥豹”、“一叶障目”只有加以整合才能见到云原生的全局风貌。面对业态各异的业务上云以及碎片化的物联网解决方案部署利用云原生思维和模式构建基于云原生的物联网平台以及解决方案势必将加速企业甚至整个社会的数字化转型。 原文链接http://www.sohu.com/a/255182751_219833.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
