编辑点评:
《持续演进的Cloud Native》希望给技术管理者、架构师和有一定基础的技术人员提供帮助,特别是希望改变研发模式,从交付型软件过渡到云服务的传统软件企业开发者,此书将帮助你少走弯路。
编辑推荐
适读人群 :软件行业的架构师、技术管理者、高级开发人员。
云原生架构是IT技术在云计算时代的进化升级,标志着云端应用进入成熟阶段,本书旨在首度提供与之匹配的成规模系统和团队亟需的完整技术体系。
云原生技术变革为解决业务快速变化带来的不确定性。本书全面介绍微服务架构演进的原则与实践,阐述分布式架构带来的数据一致性问题的解决方案。
本书传授云原生应用须满足的可用性、伸缩性,可随处运行、自动化部署和管理能力,以及如何通过持续集成及持续交付工具提高研发、测试与发布效率。
实施微服务常见误区:只关注微服务技术框架而忽视全局,没有配套的微服务流水线、基础设施自动化及对应的服务化团队和组织结构,很难达到预期收益。
内容简介
《持续演进的Cloud Native》从架构、研发流程、团队文化三个角度详细介绍了如何构建Cloud Native。作者长期活跃在研发一线,具有丰富的架构设计经验,也曾亲身经历过很多失败的架构设计,如很多团队在实施微服务架构的时候,只强调拆分服务,根本没有理解微服务架构应该怎么做。《持续演进的Cloud Native》就是想告诉读者,除了拆分服务,还要把哪些事做好,例如基础设施、一致性、性能、研发流程、团队文化等。
《持续演进的Cloud Native》共分为10 章,第1 章从整体上描述了Cloud Native 的起源、组成及原则等;从第2 章到第7 章重点描述了微服务架构、敏捷基础设施及公共基础服务、可用性、可扩展性、性能、一致性等方面的设计实践;第8 章介绍了Serverless 和Service Mesh;第9 章介绍了如何构建研发流程;第10 章介绍了如何建设团队文化。
作者简介
王启军,目前就职于华为公司架构部,负责华为公司的Cloud Native、微服务架构推进落地,前后参与了华为手机祥云4.0、物联网IoT 2.0的架构设计。曾任知名电商平台架构师,主导电商平台架构设计,包括订单、支付、价格、库存、物流等。曾就职于搜狐,负责手机微博的研发。十余年的技术历练,也曾作为技术负责人带领过近百人的团队。公众号“奔跑中的蜗牛”的作者。
Cloud Native背后的诉求
在Amazon曾经出现过一个这样的问题,当团队人数快速增长之后,沟通效率越来越低,如何提高沟通效率呢?如何减少会议呢?最好的方式当然是不开会,那么怎么才能不开会却实现高效沟通呢?那就是让各个团队关注不同的模块。拆分服务就是一种方式,让每个团队独立负责一个服务,通过契约化的接口缩小沟通范围,只要接口不发生变化,就不需要过分关注外部的变化。这就是Amazon拆分服务的初衷。
现在正处于一个业务快速增长的时代,产品需要更快的交付速度,更好的用户体验,机会转瞬即逝。为什么传统企业打不过互联网公司呢?一个重要的原因是产品的进化速度太慢,不能根据用户的反馈快速迭代,当某个功能用户使用的频率比较高时,产品的方向可能会发生转变。
交付速度的提高不能以降低可用性为代价。我们都知道更新是可用性的“天敌”,只要更新就可能发生故障。传统企业提升可用性的一种方法就是少发布、多审核,这显然是和高交付速度背道而驰的。Cloud Native通过一系列工具、方法减少发布导致的可用性问题,而不是减少发布次数。
在微服务架构中,服务数量大幅增加,性能、一致性等问题越来越严重,架构变得越来越复杂,如何解决这些问题?在本书中可以找到想要的答案。
微服务架构的起源
2005年,Peter Rodgers博士在云端运算博览会上提出微Web服务(Micro-Web-Service),将程序设计成细粒度的服务(Granular Service),以作为Microsoft下一阶段的软件架构。
其核心思想是让服务按照类似Unix管道的存取方式使用,而且复杂的服务背后使用简单URI来开放界面,任何服务都能被开放(exposed),这个设计在HP的实验室被实现,具有1改变复杂软件系统的强大力量。
2014年,Martin Fowler与James Lewis共同提出了微服务的概念,定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统,每个服务都以一个独立进程的方式运行,每个服务与其他服务使用轻量级(通常是HTTP API)通信机制。这些服务是围绕业务功能构建的,可以通过全自动部署机制独立部署,同时服务会使用最小规模的集中管理(例如Docker)能力,也可以采用不同的编程语言和数据库。
实际上,微服务的诞生绝非偶然,敏捷开发帮助我们减少浪费、快速反馈,以用户体验为目标;持续交付促使我们更快、更可靠、更频繁地改进软件;基础设施即代码
(Infrastructure As Code)帮助我们简化环境的管理,这些都是推动微服务诞生的重要因素。
如果没有这些基础,微服务架构在展现魅力的同时,可能由于各种问题导致最终失败。
从SOA架构到服务化架构,再到微服务架构,是一个逐步演进的过程。Amazon被认为是微服务的鼻祖。2015年我曾经接触过一个Amazon的工程师,他并不是特别了解微服务这个名词,直到看完Martin Fowler关于微服务的文章,才发现自己一直在做的就是微服务架构。可以说微服务架构并不是什么技术创新,而是开发过程发展到一定阶段对技术架构的要求,是在实践中不断摸索而来的。每个公司所信奉的架构思想有相同之处,但是也不尽相同。这种化繁为简的拆分方式,不只在技术上带来突破,更带来了很多潜在的价值,如关注点分离、沟通效率提升、快速演进、快速交付、快速反馈等。
Comments