Browsed by
标签:敏捷

云原生架构概述

云原生架构概述

閱讀本文約花費: 9 (分鐘)1. 什么是云原生 1.1 CNCF组织 在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。 目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。 1.2 云原生 CNCF给出了云原生应用的三大特征: 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。 动态管理:通过集中式的编排调度系统来动态的管理和调度。 面向微服务:明确服务间的依赖,互相解耦。 云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。 这边引用网上关于云原生所需要的能力和特征总结,如下图。 云原生所需要的能力和特征 1.3 The Twelve Factors 12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下: 基准代码 显式声明依赖关…

Read More Read More

微服务,如何拆分服务是精髓 | 技术前沿

微服务,如何拆分服务是精髓 | 技术前沿

閱讀本文約花費: 12 (分鐘)在《云原生基础架构最佳状态,就是没有基础架构》一文中,我们探讨了云原生基础架构的内涵及价值。   本篇我们讨论云原生的又一个重要理念——微服务。   其实之前在《理解了云原生,才能正确迎接云时代的到来》一文中已经简单阐释过微服务,它是区别于过去单一架构产品开发模式的一种新型方式,为的是持续交付这一云原生终极目标。可以说,微服务是云原生的灵魂。既然如此重要,本篇再来详细展开一下,包括什么是微服务、为什么需要微服务、微服务的设计原则等。 从历史发展看微服务起源 2005年,Peter Rodgers博士在云端运算博览会上提出微Web服务(Micro-Web-Service),将程序设计成细粒度的服务,以作为Microsoft下一阶段的软件架构。   2014年,Martin Fowler与James Lewis共同提出了微服务的概念,定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统,每个服务都以一个独立进程的方式运行,每个服务与其他服务之间使用轻量级(通常是HTTP API)通信机制。   Amazon是遇到“微服务”问题最早的公司。当年,Amazon面临着这样一个问题,当团队人数快速增长之后,沟通效率越来越低,如何提高效率,如何减少会议?最终想出来的办法是拆分服务,让各个团队关注不同的模块,让每…

Read More Read More

从PHP到Node,聊一聊淘宝首页背后的技术

从PHP到Node,聊一聊淘宝首页背后的技术

閱讀本文約花費: 22 (分鐘)“作者从2014年双十二结束时开始接手淘宝首页,经历了淘宝首页的两次改版和一次从PHP到Node的迁移,不久前完成了工作的交接。本文介绍了淘宝首页的变迁过程、性能优化、稳定性保障和敏捷措施,分享了作者在此过程中的感受。 相关背景介绍 淘宝首页是淘宝的门面,承载着几乎淘系所有业务的入口,流量很大,量级单位为亿。近几年无线端崛起,业务重点开始向无线终端偏移(目前不能叫偏移,基本以无线为主了),所以淘宝 PC 端首页的流量也有削减,不过即便如此,它的日均 PV 依然相当高。 淘宝首页一向是内部平台和技术的试验田,它一直在变化着。最新的框架和系统都会找淘宝首页试点,可以试想下,如果某一项需要推动的升级或者优化措施在淘宝首页已经上线,并且拿到了良好的数据和稳定性,其他业务还有什么理由不去尝试和更迭呢?同时,去年一年身在淘宝前端的技术架构组,自然而然也会主动去 push 一些实验性的内容到业务上。 淘系的站点页面包括首页、其他频道页和活动页等,这些页面并不都由淘宝前端一行一行的代码码出来,业务如此之多,这种玩法即便人数 double 也忙不过来。事实上,大多数页面都是依托内部的搭建平台一一运营或者前端通过模块搭建的方式一一构建的,而前端 focus 的重点在于搭建平台的建设自身以及模块的通用性和复用率的保障,当然,还有一些工程化的东西。 使用搭建平台搭建的页面,…

Read More Read More

在首席架构师手里,应用架构如此设计

在首席架构师手里,应用架构如此设计

閱讀本文約花費: 25 (分鐘) 无架构,不系统,架构是大型系统的关键。从形上看,架构是系统的骨架,支撑和链接各个部分;从神上看,架构是系统的灵魂,深刻体现业务本质。架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。本文基于作者在大型互联网系统的实践和思考,和大家一起探讨应用架构的选型。本文主要内容包括:应用架构本质单体式分布式SOA架构SOA落地方式应用架构进化应用架构本质应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面,应用架构定义系统有哪些应用、以及应用之间如何分工和合作。分有两种方式,一种是水平分,按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。另一种是垂直分,按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。应…

Read More Read More

到底什么是数据中台?

到底什么是数据中台?

閱讀本文約花費: 35 (分鐘) 文章中作者主要围绕数据中台是什么?普通企业该不该做数据中台?数据中台会带来怎样的挑战等问题谈了谈自己的看法。 导读:数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。如今似乎人人都在提数据中台,但却不是所有人都清楚数据中台到底意味着什么。数据中台是只有大厂才需要考虑的高大上的概念吗?普通企业该不该做数据中台?数据中台的出现会给现有数据从业者们带来颠覆式的挑战吗?带着上述问题,谈谈他对于数据中台的看法。 数据中台不是大数据平台! 首先它不是一个平台,也不是一个系统,如果有厂商说他们有个数据中台卖给你,对不起,它是个骗子。 要回答数据中台是什么,首先要探讨一下中台到底是什么。虽然没有明确的定义,但是作为理工直男,我们可以先把中台看作是一种中间层。既然是一种中间层,那么中台确实是一种十足技术用语,我们可以完全从技术角度来探讨了。 我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层,这样可以更好地理解中台的定位和价值。Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。 在数据开发中,核心数据模型的变化是相对缓慢的,同时,对数据进行维护的工作量也非常大;但业务创新的速度、对数据提出的需求的变化,是非常快速…

Read More Read More

Service Mesh的本质、价值和应用探索

Service Mesh的本质、价值和应用探索

閱讀本文約花費: 17 (分鐘)Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。 网上介绍 Service Mesh 的资料不少,但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家李云带领团队在这一领域探索的过程中想清楚了这两点,并在 QCon 2018 上海站分享了阿里巴巴对 Service Mesh 的探索与实践。 大规模分布式应用的挑战 微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。 在阿里巴巴内部,RPC 框架由中间件事业部统一开发与维护,以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演…

Read More Read More

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

程序员必读书单 1.0

程序员必读书单 1.0

閱讀本文約花費: 80 (分鐘)本文把程序员所需掌握的关键知识总结为三大类19个关键概念,然后给出了掌握每个关键概念所需的入门书籍,必读书籍,以及延伸阅读。旨在成为最好最全面的程序员必读书单。 前言 Reading makes a full man; conference a ready man; and writing an exact man. Francis Bacon 优秀的程序员应该具备两方面能力: 良好的 程序设计 能力: 掌握常用的数据结构和算法(例如链表,栈,堆,队列,排序和散列); 理解计算机科学的核心概念(例如计算机系统结构、操作系统、编译原理和计算机网络); 熟悉至少两门以上编程语言(例如 C++,Java,C#,和 Python); 专业的 软件开发 素养: 具备良好的编程实践,能够编写可测试(Testable),可扩展(Extensible),可维护(Maintainable)的代码; 把握客户需求,按时交付客户所需要的软件产品; 理解现代软件开发过程中的核心概念(例如面向对象程序设计,测试驱动开发,持续集成,和持续交付等等)。 和其它能力一样, 程序设计 能力和 软件开发 素养源自项目经验和书本知识。项目经验因人而异(来自不同领域的程序员,项目差异会很大);但书本知识是相通的…

Read More Read More

Medium开发团队谈架构设计

Medium开发团队谈架构设计

閱讀本文約花費: 16 (分鐘) 背景   说到底,Medium是个社交网络,人们可以在这里分享有意思的故事和想法。据统计,目前累积的用户阅读时间已经超过14亿分钟,合两千六百年。   我们支持着每个月两千五百万的读者以及每周数以万计的文章发布。我们不想Medium的文章以阅读量为成功的依据,而是观点取胜。在Medium,文章的观点比作者的名头更重要。在这里,对话促进想法,并且很看重文字的力量。   我是Medium开发团队的负责人,此前在Google工作,负责开发Google+和Gmail,还创立了Closure项目。业余时间我喜欢滑雪跳伞和丛林冒险。   团队介绍   说起团队我非常自豪,这是一群富有好奇心而且想法丰富的天才,大家凑到一块是想做大事的。   团队以跨功能的任务驱动,这样每个人既可以专攻,又可以毫无压力的对整个架构有所贡献。我们的理念就是接触的方面越多,对团队的锻炼越大。更多关于团队的理念见此。   在工作组织方面,我们有着很大的自由度,当然作为一个公司组成,我们还是有季度目标的,并且鼓励敏捷开发模式。我们使用GitHub进行code review和问题跟踪,用Google Apps作为邮件、文档和表单系统。跟很多团队习惯使用Trello不同,我们是Slack和slack机器人的重度用户。   原始架构   最开始的时候,Medium部署在EC2上,用Node.j…

Read More Read More

云原生:「落地」最重要

云原生:「落地」最重要

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了,但到底怎么去理解它,还是需要一段过程。提到云原生,很多人会联想到另一个词:「互联网原住民」,这个词代表了一群出生在互联网时代的人,他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统,不再是原来的那套思考方式,不是把云当成一个工具来使用,而是系统本身就生长于云,并在云上爆发,因此需要我们从根本上转换思考方式,重新定义业务系统。云原生和云计算也不一样,云计算的主角是计算、机器、资源,而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事: 在 2004 年那个缺电的夏天,淘宝网全都挤在华星二楼:正是在那里,开始了我的淘宝生涯。我的位置在一个角落里,边上是一堆开着的服务器,吹出的风比七月烈阳下的风更热:因为限电,空调基本上只能看。刚到一个新环境,不知道该做什么,眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的,我记得小宝有一次说,当时网站如果要改点什么,只要跑到多隆那儿说一下,等他接杯水回到座位打开页面时,需求就已经上线了。 那是 2004 年,基于当时的技术架构,任何需求只要改一下代码,就能够立刻交付。而在现在这样复杂的技术架构下,很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来,我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

敏捷过程中如何保证代码质量

敏捷过程中如何保证代码质量

閱讀本文約花費: 10 (分鐘)本文目录: 一、为什么要做代码质量分析 二、常见的代码质量分析工具 三、DevOps平台中的代码质量分析 四、DevOps平台中如何为代码质量提供保障 一、为什么要做代码质量分析 在软件开发过程中,当一个功能开发完成后,如何去保证代码是可用的、没问题的?一般情况下,基本都会有单元测试、每日构建、功能测试等环节来保证。但是,保证代码可用就够了吗?显然不是。 一个软件项目开发完一个版本会有下一个版本,会有新的需求,原来的功能也可能会变更。你写的代码可能会被别人使用,你也可能需要修改别人写的代码。如果只考虑代码的可用性,不考虑代码质量,那么后期遇到的问题其维护成本将会很高,不利于版本迭代。为了避免或减少维护和迭代成本,重视代码质量,做好代码质量分析和管控是最好的方式。 二、常见的代码质量分析工具 既然要做代码质量分析,那我们先看看常用的代码分析工具。 PMD: 注重检查源文件中的潜在问题,可以检查Java代码中是否有未使用的变量、私有方法,是否有空的try/catch、是否过于复杂的表达式等等。 CheckStyle:注重代码格式、代码规范,通过检查编码格式、命名约定、Javadoc、类设计等方面进行代码规范和风格的检查,从而有效约束开发人员更好地遵循代码编写规范,提供常见IDE的插件,如eclipse,IDEA等。 FindBugs:注重检测潜在的Bug…

Read More Read More

Nacos 企业级落地实践

Nacos 企业级落地实践

閱讀本文約花費: 16 (分鐘)前言 在高速发展的时候,公司规模越来越大,老师人数越来越多,这时候公司不能铺太多人去做运营与服务,必须提高每个人效,这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司,如果被迫成为一家靠资金驱动的公司就活不下去了。 ——张翼(掌门教育创始人兼 CEO) 掌门教育自 2014 年正式转型在线教育以来,秉承“让教育共享智能,让学习高效快乐”的宗旨和愿景,经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ,一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展,特别是今年的疫情,使在线教育成为了新的风口,也给掌门教育新的机遇。 随着业务规模进一步扩大,流量进一步暴增,微服务数目进一步增长,使老的微服务体系所采用的注册中心 Eureka 不堪重负,同时 Spring Cloud 体系已经演进到第二代,第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模,同时它目前被 Spring Cloud 官方置于维护模式,将不再向前发展。如何选择一个更为优秀和适用的注册中心,这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、HashiCorp Consul 等开源注册中心做了深入的调研和比较,最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 掌门教育微服务面临…

Read More Read More

部署策略对比:蓝绿部署、金丝雀发布及其他

部署策略对比:蓝绿部署、金丝雀发布及其他

閱讀本文約花費: 13 (分鐘)目前,软件开发最大的变化是部署频率。产品团队更早(更频繁)的将产品发布到生产环境。数月或者数年的发布周期变得越来越短 – 对那些构建纯软件产品的人来说更是如此。 现在,使用面向服务的架构和微服务方式,开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。 缩短部署周期的业务优势狠明显: 缩短上市时间 客户可以在更短的时间内获得产品价值 客户的反馈也会更快的到达产品团队,这意味着团队可以更快的迭代特性和修复问题 开发人员的整体士气会上升 但是,这种转变也给运维或者 DevOps 团队带来了新挑战。更频繁的部署,意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因,因为它可以最大限度的降低产品和客户的风险。 在本文中,我们将讨论不同的部署策略、最佳实践和工具,让你的团队可以更快更可靠的工作。 现代应用的挑战 现代应用通常是分布式的,基于云的。它们可以弹性扩展来满足需求,基于高可用架构更好地容错。这些应用可以使用全托管服务,例如 AWS Lambda 和 Elastic Container Service(ECS) 等平台处理一些运维责任。 这些应用经常频繁部署。例如,移动 app 和 web 应用可能一个月内经历多次更改。有些甚至一天…

Read More Read More

微服务与网关技术(SIA-GateWay)

微服务与网关技术(SIA-GateWay)

閱讀本文約花費: 18 (分鐘) 编辑推荐:文章主要介绍了微服务架构特性,微服务网关的分类以及作用,SIA-GateWay等,希望能对您有所帮助。 一. 背景 软件架构,总是在不断的演进中… 把时间退回到二十年之前,当时企业级领域研发主要推崇的还是 C/S 模式,PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移,基于浏览器的的 B/S 架构开始渐渐流行了起来。初期,Web 开发 ASP 还占据了不少优势,但 JSP 的预编译模式让性能有了很大的提升,随后基于 JAVA 语言的 J2EE 架构变的越来越流行。 早期软件架构基本都是单体架构,系统之间往往不需要进行交互,这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多,相互的关系也越来密切。应用之间也迫切需要进行实时交互访问,随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用,SOA 的概念被提了出来,web service 逐渐流行起来。 互联网时代,很多公司为了适应更加灵活的业务需求,基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践,在 SOA 架构中,企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此,微服务架构逐渐流行起来。 在《微服务设计》中如…

Read More Read More

开好回顾会议需要解决这四个问题

开好回顾会议需要解决这四个问题

閱讀本文約花費: 20 (分鐘)持续改进是敏捷的重要组成部分。无论一个敏捷团队今天多么出色,都要推动其团队成员去寻求未来变得更好的方法。而探索持续改进,正是迭代回顾会议的目的。 不幸的是,并非所有回顾会议都能实施得很好。许多团队往往很难开好回顾会议。在本文中,我将描述自己在回顾会议中看到的四个最常见问题,并提供解决问题的建议。   问题1:人们不诚实或不值得信任  对回顾会议最常见的抱怨之一是:人们没有提出真正的问题或人们不愿意承认他们的问题。如果人们不能在回顾会议上直言不讳,那么得到的评论也只能是“浪费时间”。 这或许是个真实存在的问题,但解决方案不是抛弃回顾会议,而是我们要关注如何让人们在回顾会议中变得更加诚实和开放。 您一定能采取一些措施来增强团队成员之间的诚实和互信。具体可以执行以下措施: 1)营造安全氛围 要营造安全氛围,因为只要缺乏安全感,人们就不会在回顾会议上畅所欲言。这就意味着——人们在回顾会议上说的话和发生的事都不会蔓延到会后,并且这一点已深入人心。 只要参加足够多的回顾会议,您就会偶尔看到情绪失控的情况,您还会听到不该重复出现的话语。在最近一次回顾会议上,就有一位程序员咆哮:“到底还要等多久,‘该死的DevOps组’才能执行部署工作?”。 他确实不应该那样说话。但换句话说,他能发泄出情绪,并且在发泄完后明白不能再这样与DevOps组…

Read More Read More

团队间差异大,如何统一估算基准?

团队间差异大,如何统一估算基准?

閱讀本文約花費: 9 (分鐘)实施规模化敏捷时,组织管理多个Scrum团队时将面临更多的挑战。如果您已让多个团队工作于同一个项目,那么协作会变得更复杂,特别是估算的时候。 这些团队需要进行估算和制定计划,并基于计划来跟踪进度,以便PO能安排其工作优先顺序,在有成果物交付时与干系人进行交流。 但多个Scrum团队共同工作会带来更多的挑战,包括: 团队技能和经验水平都不同时,该如何处理? 怎样才能在无需每位团队成员都参与的情况下准确估算工作? 在不知道该由哪个团队来承接工作的情况下,怎样完成估算? 我将与大家分享一个解决方案。但在此之前,让我们先来看看大多数组织在为多个Scrum团队做估算时都会犯的两个关键错误。   错误1:估算不能反映所有团队的能力 第一个错误往往发生在公司挑选一组人员来估算整个待办项时。这本身并不是一个坏主意(事实上稍后我会建议您这么做)。与让大团队每个人都参与每个待办项的估算相比,这样么做当然会更快、更高效。并且或许您还会认为,只要选择的人员合适,估算结果就会是富有见地的。 但这正是事情容易出错的地方,因为一旦缺乏熟悉即将开展的工作且能真正代表所有Scrum团队的人员,您就会得到基于非常片面和不准确的视角而生成的估算值。 不幸的是,目前许多公司正在发生这样的事情:估算数据由那些脱节于即将开展的工作及其实施团队的人员创建。 这样做的结果之一是:…

Read More Read More

Scroll Up