文章吧-经典好文章在线阅读:Cloud Native 分布式架构原理与实践读后感100字

当前的位置:文章吧 > 原创文章 >

Cloud Native 分布式架构原理与实践读后感100字

2020-10-17 19:50:02 来源:文章吧 阅读:载入中…

Cloud Native 分布式架构原理与实践读后感100字

  《Cloud Native 分布式架构原理与实践》是一本由柳伟卫著作,北京大学出版社出版的平装图书,本书定价:79,页数:336,特精心从网络上整理的一些读者的读后感,希望对大家能有帮助。

  《Cloud Native 分布式架构原理与实践》精选点评:

  ●老卫我都是你的铁杆粉丝了,加油哦,太喜欢你的书了。我会好好学习的,很好的好货。必须赞

  ●老实说,有点失望,比华为王启军的那本差不少,基本都是各类SPRING BOOT,SPRING ,SPRING CLOUD的知识章节的堆砌,每个部分其实写的还详细,但感觉没主线贯穿,没实例。最多只能65分

  ●比较水。本书的云原生仅仅是Spring Cloud框架的使用。

  ●《Cloud Native分布式架构原理与实践》国内Java 领域关于 Cloud Native(云原生) 的重量级专著,理论联系实战的云架构指南。支持老卫!

  ●我特意掐着表,一共花了10分钟不到翻完。这本书定价79块。此君的书之前读过另外一本,水平统一,以后要绕道而行了。

  《Cloud Native 分布式架构原理与实践》读后感(一):弟兄们,一起拥抱上云

  未来越来越多的企业将会“拥抱云”。特别是对于中小企业及个人开发者而言,以云架构为优先的 Cloud Native 应用开发模式将会深入人心。Cloud Native 能帮助企业快速推出产品,同时节省成本。 笔者结合自身的云计算工作经验,以及对于 Cloud Native 的思考,将这方面的知识整理成册,内容涵盖 REST 设计、测试、服务注册、服务发现、安全、数据管理、消息通信、批处理、任务调度、运营、 容器部署、持续发布等方面的知识,希望帮助读者从理论和实践两方面来深刻理解 Cloud Native。 看好未来云的优势和发展前景。让我们一起拥抱上云!

  《Cloud Native 分布式架构原理与实践》读后感(二):学习Cloud Native,适应未来开发趋势

  目前,越来越多的企业已经在大规模开始拥抱云,在云环境开发应用、部署应用、发布应用。Cloud Native(云原生)是以云架构为优先的应用开发模式。那么,为什么说 Cloud Native 是未来开发应用的趋势呢?

什么是 Cloud Native

  Cloud Native (国内译为“云原生”),最早是 Matt Stine 提出的一个概念。与微服务一样,Cloud Native 并不是一种具体的技术,而是一类思想的集合,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等,以及根据商业能力对公司进行重组。Cloud Native 既包含技术(微服务,敏捷基础设施),也包含管理(DevOps,持续交付,康威定律,重组等)。所以,Cloud Native 也可以说是一系列Cloud技术、企业管理方法的集合。

  有关Cloud Native的概述,可见“简述 Cloud Native”一文的论述。

为什么说 Cloud Native 是大势所趋

  目前,越来越多的企业已经开始拥抱云,在云环境下开发应用、部署应用和发布应用。未来,越来越多的开发者也将采用 Cloud Native 来开发应用。

  那么,为什么说 Cloud Native 是大势所趋

1. 云计算带来的是成本的节约和业务的敏捷性

  特别是使用云计算所提供的基础设施,费用会更加低廉。随着云计算的不断发展,企业越来越倾向于使用 IaaS(基础设施即服务)和 PaaS(平 台即服务)来构建应用程序。这种应用可以利用云计算的弹性和可伸缩性,同时还能满足云环境下的容错性。

2. 很多企业倾向于使用微服务架构来开发应用

  微服务开发快速、职责单一,能够更快速地被客户所采纳。同时,这些应用能够通过快速迭代的方式得到进化,赢得客户的认可。Cloud Native 可以打通微服务开发、测试、部署、发布的整个流程环节。

3. 云供应商为迎合市场,提供了满足各种场景方案的 API

  例如,用于定位的 Google Maps,用于社交协作的认证平台等。将这些 API 与企业业务的特性和功能结合在一起,可以让它们为客户构建独特的方案。所有整合都在 API 层面进行。这意味着,无论是移动应用还是传统的桌面应用都能无缝集成。所以,采用 Cloud Native 所开发的应用都具备极强的可扩展性。

4. 软件不可能不出故障

  传统的企业级开发方式需要有专职人员来对企业应用进行监控与维护。而在 Cloud Native 架构下,底层的服务或 API 都将部署到云中,相当于将繁重的运维工作转 移给了云平台供应商。这意味着客户应用将得到更加专业的看护,同时也节省了运维成本。

如何实现 Cloud Native

  那么如何来实现 Cloud Native 呢?其实这是一个非常大的话题,比如,作为开发者,你需要了解目前市面上流行的云供应商,了解微服务、SOA,了解 HTTP 和 REST,了解领域驱动设计(DDD),了解CICD和TDD,了解两个披萨,了解分布式的常用架构和模式等等。这里每一样都是一个庞大的课题,还好目前市面上已经有了一些资料可供学习,比如老卫的这本《Cloud Native 分布式架构原理与实践》这本书,可以非常全面的指导开发者轻松入门 Cloud Native。

  《Cloud Native 分布式架构原理与实践》读后感(三):轻松入门Cloud Native

  Cloud Native(云原生)是以云架构为优先的应用开发模式。目前,越来越多的企业已经在大规模开始拥抱云,在云环境开发应用、部署应用、发布应用。未来,越来越多的开发者也将采用 Cloud Native 来开发应用。本书是国内第一本 Java 领域 Cloud Native 著作。

  那么为什么Cloud Native模式会越来越流行?Cloud Native与微服务有什么区别?何时选择使用Cloud Native?等等,这些问题将在老卫的新作《 Cloud Native 分布式架构原理与实践》中已经一一解答。

  什么是 Cloud Native

  Cloud Native (国内译为“云原生”),最早是 Matt Stine 提出的一个概念。与微服务一样,Cloud Native 并不是一种具体的技术,而是一类思想的集合,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等,以及根据商业能力对公司进行重组。Cloud Native 既包含技术(微服务,敏捷基础设施),也包含管理(DevOps,持续交付,康威定律,重组等)。所以,Cloud Native 也可以说是一系列Cloud技术、企业管理方法的集合。

  Cloud Native 具备有以下特性:

以云为基础架构云服务无服务可扩展高可用敏捷云优先等等

  下图是《Cloud Native 分布式架构原理与实践》书中所罗列的 Cloud Native 云架构模式。可见 Cloud Native 体系是非常庞杂的。

  随着云计算的不断发展,企业开始采用基础架构即服务(IaaS)和平台即服务(PaaS)服务,并利用它们构建利用云的弹性和可伸缩性的应用程序,同时也能够满足云环境下的容错性。同时,云环境更加便宜和经济,因此,未来云环境会被作为企业部署、个人开发的优先选择。Cloud Native 的出现恰逢其时, 其架构可以指导企业或者个人轻松实现云应用开发或者云部署。

  Cloud Native 与微服务的关系

  在“简述 Microservices(微服务)”一文中,已经对微服务的概念做了简单的论述。

  微服务架构风格其本质是把大的应用拆分成为小的服务(微服务)。微服务是单一应用的形式, 因此可以独立部署和运行在其自己的进程中。微服务一般采用轻量级的机制进行通信(一般是 HTTP 资源 API),因此可以不限制技术栈。微服务是围绕业务能力来构建,因此更加聚焦业务能力,能够把握住领域边界,放置需求的蔓延。微服务其固有的特性,方便通过全自动部署工具来实现独立部署,因此非常适合在云环境中进行部署。

  在 Cloud Native 中,倾向于使用微服务来构建应用。同时,Cloud Native因为是以云环境为优先的,非常适合微服务的部署和管理。

  目前,业界针对微服务有非常多的成熟方案,比如 Spring Boot、Spring Cloud 等,都可以简化微服务的开发工作。这微服务方面,笔者也撰写了一些列的免费教程(https://waylau.com/books/),读者朋友可以作为参考。

  为什么我们需要使用 Cloud Native?

  云计算的第一个浪潮是关于成本节约和业务敏捷性,尤其是云计算的基础设施更加廉价。

  很多企业倾向于使用微服务架构来开发应用。微服务开发快速,职责单一,能够更快速的被客户所采纳。同时,这些应用能够通过快速迭代的方式,得到进化,赢得客户的认可。Cloud Native 可以打通微服务开发、测试、部署、发布的整个流程环节。

  云供应商为迎合市场,提供了满足各种场景方案的 API,例如用于定位的 Google Maps,用于社交协作的认证平台等。将所有这些 API 与企业业务的特性和功能混合在一起,可以让他们为客户构建独特的方案。所有这些整合都在 API 层面进行。这意味着,不管是移动应用还是传统的桌面应用都能无缝集成。所以,采用 Cloud Native 所开发的应用都且具备极强的可扩展性。

  软件不可能不出故障。传统的企业级开发方式,需要有专职人员来对企业应用进行监控与维护。而在 Cloud Native 架构下,底层的服务或者是 API 都由将部署到云中,等价于将繁重的运维工作转移给了云平台供应商。这意味着客户应用将得到更加专业的看护,同时,也节省了运维成本。

  因此,云是大势所趋。快来拥抱Cloud Native!

  如何实现 Cloud Native

  那么如何来实现 Cloud Native 呢?其实这是一个非常大的话题,比如,作为开发者,你需要了解目前市面上流行的云供应商,了解微服务、SOA,了解 HTTP 和 REST,了解领域驱动设计(DDD),了解CICD和TDD,了解两个披萨,了解分布式的常用架构和模式等等。这里每一样都是一个庞大的课题,还好目前市面上已经有了一些资料可供学习,比如《Cloud Native 分布式架构原理与实践》,可以非常全面的指导开发者轻松入门 Cloud Native。

  在本文的最后也列出了一些学习资料,读者有兴趣的话,可以由点及面,慢慢扩展自己的知识体系。

  参考引用

原文同步至:https://waylau.com/about-cloud-native/

  《Cloud Native 分布式架构原理与实践》读后感(四):当今软件发展的现状非常适合 Cloud Native 环境

  当今软件行业正发生着巨变。自上世纪50年代计算机诞生以来,软件从最初的手工作坊式的交付方式,逐渐演变成为了职业化开发、团队化开发,进而定制了软件件行业的相关规范,形成了软件产业。 今天,无论是大型企业还是个人开发者,都或多或少采用了云的方式来开发、部署应用。不管是私有云,还是公有云,都终将给整个软件产业带来的革命。个人计算机或者以手机为代表的智能设备已经走进寻常百姓家了。每个人几乎都拥有手机,手机不仅仅是通信工具,还能发语音、看视频、玩游戏,让人与人之间的联系变得更加紧密。智能手环随时监控你的身体状况,并根据你每天的运动量、身体指标来给你提供合理的饮食运动建议。出门逛街甚至不需要带钱包了,吃饭购物搭车时使用手机就可以支付费用,多么方便快捷。智能家居系统更是你生活上的“管家”,什么时候该睡觉了,智能家居系统就自动拉上窗帘,关灯;早上起床了,智能家居系统会自动拉开窗帘,并播放动人的音乐,让你可以愉快地享受新的一天的来临;你再也不用担心家里的安全情况,智能家居系统会帮你监控一切,有异常情况时会及时发送通知到你的手机,让你第一时间掌握家里的状况。未来,每个人都能够拥有《Iron Man》(钢铁侠)中所描述的智能管家 Jarvis。而这一切,都离不开背后那个神秘的巨人——分布式系统。正是那些看不见的分布式系统,每天处理着数以亿计的计算,提供可靠而稳定的服务。这些系统往往是以 Cloud Native 方式来部署、运维的。 ## 软件需求的发展 早期的软件,大多数是由使用该软件的个人或机构研制的,所以软件往往带有非常强烈的个人色彩。早期的软件开发也没有什么系统的方法论可以遵循,完全是“个人英雄主义”,也不存在所谓的软件设计,纯粹就是某个人的头脑中思想的表达。而且,当时的软件往往是围绕硬件的需求来定制化开发的,有什么样的硬件就有什么样的软件。所以,软件缺乏通用性。同时,由于软件开发过程不需要与他人协作,所以,软件除了源代码外,往往没有软件设计、使用说明书等文档。这样,就造成了软件行业缺乏经验的传承。 从60年代中期到70年代中期是计算机系统发展的第二个时期,在这一时期软件开始被当作一种产品被广泛使用。所谓产品,就是可以提供给不同的人使用,从而提高了软件的重用率,降低了软件开发的成本。比如,以前,一套软件,只能专门提供给某个人使用。现在,同一套软件可以批量的卖给不同的人,显然,分摊到相同软件上的开发成本而言,卖的越多,成本自然就越低。这个时期,出现了类似“软件作坊”的专职替别人的开发软件的团体。虽然是团体协作,但软件开发的方法基本上仍然沿用早期的个体化软件开发方式,这样导致的问题是,软件的数量急剧膨胀,软件需求日趋复杂,软件的维护难度也就越来越大,开发成本变得越来越高了,从而导致软件项目频频遭遇失败。这就演变成了“软件危机”。 “软件危机”迫使人们开始思考软件的开发方式,使得人们开始对软件及其特性进行了更加深入的研究,人们对待软件的观念也在发生悄然的改变。在早期,由于计算机的数量很少,只有少数军方或者科研机构才有机会接触到计算机,这就让大多数人认为,软件开发人员都是稀少且优秀的(一开始确实也是如此,毕竟计算机最初制作者都是数学界的天才)。由于,软件开发的技能,只能被少数人所掌握,所以大多数人对于“什么是好的软件”缺乏共识。实际上,早期那些被认为是优秀的程序常常很难被别人看懂,里面充斥着各种程序技巧。加之,当时的硬件资源比较紧缺,迫使开发人员在编程时,往往需要考虑更少的占用机子资源,从而会采用不易阅读的“精简”方式来开发,这更加加重了软件的个性化。而现在人们普遍认为,优秀的程序除了功能正确,性能优良之外,还应该更加让人容易看懂、容易使用、容易修改和扩充。这就是软件可维护性的要求。 1968年 NATO 会议上首次提出“软件危机”(Software Crisis)这个名词,同时,提出了期望通过“软件工程(Sotfwrae Engineeirng)”来解决“软件危机”。“软件工程”的目的,就是要把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”进行转化,从而解决“软件危机”包含两方面问题: * 如何开发软件,以满足不断增长,日趋复杂的需求; * 如何维护数量不断膨胀的软件产品。

  事实证明,在软件的可行性分析方面,事先对软件的进行可行性分析,可以有效的规避软件失败的风险,提高软件的开发的成功率。 在需求方面,软件行业的规范是,需要制定相应的软件规格说明书、软件需求说明书,从而让开发工作有了依据,划清了开发边界,并在一定程度上减少了“需求蔓延”的情况的发生。 在架构设计方面,需制定软件架构说明书,划分了系统之间的界限,约定了系统间的通信接口,并将系统分为多个模块。这样,更容易将任务分解,从而降低系统的复杂性。 今天,制定软件需求的方式越来越多样化了。客户与系统分析师也许只是经过简单的口头讨论,制定了粗略的协议,就安排开发工程师进行原型设计了。开发工程师开发一个微服务,并部署到云容器中,从而可以实现软件的交付。甚至,可以不用编写任何写后台代码,直接使用云服务供应商所提供的 API,使应用快速推向市场。客户在使用完这个应用时,马上就能将自己体验反馈到开发团队,使开发团队能够快速的响应客户的需求变化,并促使软件进行升级。 通过敏捷的方式,最终软件形成了“开发——测试——部署——反馈”的良性循环,软件产品也得到了进化。而这整个过程,都比传统的需求获取的方式将更加的迅捷。 ## 开发方式的巨变 早些年,瀑布模型还是标准的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。 瀑布模型优点是严格遵循预先计划的步骤顺序进行,一切按部就班,整个过程比较严谨。同时,瀑布模型强调文档的作用,并要求每个阶段都要仔细验证文档的内容。但是,这种模型的线性过程太理想化,主要存在以下几个方面的问题在: * 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量; * 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险; * 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果; * 各个软件生命周期衔接花费时间较长,团队人员交流成本大。 瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的,所以瀑布式方法非常适合需求明确的软件开发。但在如今,时间就是金钱,如何快速抢占市场,是每个互联网企业需要考虑的第一要素。所以,快速迭代、频繁发布的原型开发、敏捷开发方式,被越来越多的互联网企业所采用。甚至,很多传统企业,也在逐步向敏捷的“短平快”的开发方式靠拢。毕竟,谁愿意等待呢? 客户将需求告诉了你,当然是越快希望得到反馈越好,那么,最快的方式莫过于在原有系统的基础上,搭建一个原型提供给客户作为参考。客户拿到原型之后,肯定会反馈他的意见,是好或者坏的方面都会有。这样,开发人员就能根据客户的反馈,来对原型进行快速更改,快速发布新的版本,从而实现了良好的反馈闭环。 今天,Cloud Native 的开发方式正在流行。Cloud Native 是以云架构为优先的应用开发模式。Cloud Native 利于最大化整合现有的云计算所提供的资源,同时也最大化节约了项目启动的成本。 ## 云是大势所趋

  目前,越来越多的企业已经在大规模开始拥抱云,在云环境开发应用、部署应用、发布应用。未来,越来越多的开发者也将采用 Cloud Native 来开发应用。 那么,为什么我们需要使用 Cloud Native? * 云计算的第一个浪潮是关于成本节约和业务敏捷性,尤其是云计算的基础设施更加廉价。随着云计算的不断发展,企业开始采用基础架构即服务(IaaS)和平台即服务(PaaS)服务,并利用它们构建利用云的弹性和可伸缩性的应用程序,同时也能够满足云环境下的容错性。 * 很多企业倾向于使用微服务架构来开发应用。微服务开发快速,职责单一,能够更快速的被客户所采纳。同时,这些应用能够通过快速迭代的方式,得到进化,赢得客户的认可。Cloud Native 可以打通微服务开发、测试、部署、发布的整个流程环节。 * 云供应商为迎合市场,提供了满足各种场景方案的 API,例如用于定位的 Google Maps,用于社交协作的认证平台等。将所有这些 API 与企业业务的特性和功能混合在一起,可以让他们为客户构建独特的方案。所有这些整合都在 API 层面进行。这意味着,不管是移动应用还是传统的桌面应用都能无缝集成。所以,采用 Cloud Native 所开发的应用都且具备极强的可扩展性。 * 软件不可能不出故障。传统的企业级开发方式,需要有专职人员来对企业应用进行监控与维护。而在 Cloud Native 架构下,底层的服务或者是 API 都由将部署到云中,等价于将繁重的运维工作转移给了云平台供应商。这意味着客户应用将得到更加专业的看护,同时,也节省了运维成本。

  那么如何来实现 Cloud Native 呢?其实这是一个非常大的话题,比如,作为开发者,你需要了解目前市面上流行的云供应商,了解微服务、SOA,了解 HTTP 和 REST,了解领域驱动设计(DDD),了解CICD和TDD,了解两个披萨,了解分布式的常用架构和模式等等。这里每一样都是一个庞大的课题,还好目前市面上已经有了一些资料可供学习,比如《[Cloud Native 分布式架构原理与实践](https://item.jd.com/12496131.html)》,可以非常全面的指导开发者轻松入门 Cloud Native。

  ## 参考引用 * 原文同步至:<https://waylau.com/the-way-to-cloud-native/> * [Cloud Native 案例大全](ttps://github.com/waylau/cloud-native-book-demos) * [简述 Microservices(微服务)](https://waylau.com/ahout-microservices/) * [Spring Boot 企业级应用开发实战](https://github.com/waylau/spring-boot-enterprise-application-development) * [Spring Cloud 微服务架构开发实战](https://github.com/waylau/spring-cloud-microservices-development) * [Cloud Native 分布式架构原理与实践](https://item.jd.com/12496131.html) * [分布式系统常用技术及案例分析](https://github.com/waylau/distributed-systems-technologies-and-cases-analysis)

评价:

[匿名评论]登录注册

评论加载中……