Browsed by
标签：敏捷

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

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

Comments 0 Comment  10 Views

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

Read More Read More

到底什么是数据中台？

到底什么是数据中台？

Comments 0 Comment  27 Views

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

Read More Read More

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

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

Comments 0 Comment  60 Views

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

Read More Read More

程序员必读书单 1.0

程序员必读书单 1.0

Comments 0 Comment  49 Views

閱讀本文約花費: 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开发团队谈架构设计

Comments 0 Comment  52 Views

閱讀本文約花費: 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

云原生：「落地」最重要

云原生：「落地」最重要

Comments 0 Comment  79 Views

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

Read More Read More

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

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

Comments 0 Comment  75 Views

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

Read More Read More

Nacos 企业级落地实践

Nacos 企业级落地实践

Comments 0 Comment  61 Views

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

Read More Read More

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

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

Comments 0 Comment  208 Views

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

Read More Read More

微服务与网关技术（SIA-GateWay）

微服务与网关技术（SIA-GateWay）

Comments 0 Comment  132 Views

閱讀本文約花費: 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

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

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

Comments 0 Comment  103 Views

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

Read More Read More

团队间差异大，如何统一估算基准？

团队间差异大，如何统一估算基准？

Comments 0 Comment  136 Views

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

Read More Read More

SpringCloud Alibaba——服务注册与发现（Nacos）

SpringCloud Alibaba——服务注册与发现（Nacos）

Comments 0 Comment  148 Views

閱讀本文約花費: 5 (分鐘)一、Nacos简介 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 安装Nacos 下载地址(版本：0.7.0) Linux：sh startup.sh? Windows：startup.cmd? 访问：http://127.0.0.1:8848/nacos，可以进入Nacos的服务管理页面： 二、SpringCloud整合Nacos 完成了Nacos服务的安装和启动之后，下面就可以编写两个应用（服务提供者与服务消费者）来验证服务的注册与发现了。 spring cloud的版本以及spring cloud alibaba的版本，由于spring cloud alibaba还未纳入spring cloud的主版本管理中，所以需要自己加入，添加依赖文件（父工程）： <properties><java.version>1.8</java.version><spring-cloud.version>Finchley.RELEASE</spring-cloud….

Read More Read More

如何写出无法维护的代码

如何写出无法维护的代码

Comments 0 Comment  185 Views

閱讀本文約花費: 17 (分鐘)酷壳里有很多我觉得很不错的文章，但是访问量最大的却是那篇《6个变态的Hello World》，和它能在本站右边栏“全站热门”中出现的还有“如何加密源代码”，以及编程真难啊等这样的文章。可见本站的读者们的偏好，我也相信你们都是“身怀绝技”的程序员。所以，今天给大家推荐这篇文章，相信一定能触动大家的兴奋点。 这篇文章的原文在这里（http://mindprod.com/jgloss/unmain.html），我看完后我想说—— 什么叫“创造力”，创造力就是——就算是要干一件烂事都能干得那么漂亮那么有创意的能力。 什么叫“抓狂”，抓狂就是——以一种沉着老练的不屈不挠的一本正经的精神一点一点把你推向崩溃的边缘。 我把文章节选了一些，也并没有完全翻译，简译一下，也加入了一些自己的调侃。对于有下面这些编程习惯的朋友，请大家对号入座。另外，维护程序的朋友们，你们死定了！！ If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. （如果建筑师盖房子就像程序员写程序一样，那么，第一只到来的啄木鸟就能毁掉我们的文明） ~ Gerald Weinberg…

Read More Read More

《microservice & serverless》的一点感想

《microservice & serverless》的一点感想

Comments 0 Comment  152 Views

閱讀本文約花費: 6 (分鐘)超哥是来自Amazon的顶级的架构师，经历了Amazon整个向微服务架构迁移的过程，以及向serverless的演化过程，有着极其丰富的经验，年过40，一直站在技术的最前沿，始终保持对技术的执着追求和热情，是名副其实的技术大牛，能与之一起工作，荣幸之至！今天超哥给我们分享的主题《microservice & serverless》，是超哥实际工作经验的一些分享，也为公司架构的演化提供了新的思路和指导。 microservice（微服务）这个可能是这些年最火的一种架构设计了，频繁地出现在各种技术大会上，各大互联网巨头纷纷向这种架构演化，很多小的互联网公司也往这些概念上去靠，大有一种不做微服务就要落伍的趋势。事实上，很多对于微服务的理解比较粗浅，盲目的微服务化甚至会带来更多的负面影响。 目前Amazon内部运行着超过2w过微服务，但是这些微服务并不是凭空产生的，在这之前，运行的服务都是超大的单体服务，但是随着业务的发展，这种服务在整个研发的pipeline（设计→研发→编译→测试→发布→部署→运维）中都出现了一些问题。设计阶段，老的单体服务会给我们带来一些技术限制，比如有些技术只有python语言的实现，但是我们的服务使用java开发，这样我们不得不拿出一个更复杂的设计去解决类似的问题；研发阶段，随着开发人数越来越多，代码冲突的问题越来越多，我们不…

Read More Read More

阿里玄难：面向不确定性的软件设计几点思考

阿里玄难：面向不确定性的软件设计几点思考

Comments 0 Comment  144 Views

閱讀本文約花費: 19 (分鐘) 在纷繁复杂的业务发展中，变化已成为了唯一的不变。如何保障基础设施的安全、高可用性，同时提供高效的创新支持？今天，阿里副总裁、业务平台事业部掌门人玄难，结合阿里巴巴业务平台建设和个人多年大型软件设计经验，提炼成几点思考，希望对大家的软件架构设计有所启发。 玄难 阿里副总裁 业务平台事业部掌门人 特别说明：本文中所说的软件都指代面向最终用户的偏业务的软件，不包含操作系统、中间件等系统软件。 1、软件发展的几个阶段 软件工具和信息化阶段：软件最早是为了数值计算，以工具的形态出现的。包括PC时代我们非常熟悉的Excel，Word这些好东西。以及典型的企业内部管理的信息系统，例如：企业流程审批、进销存管理系统等等。 互联网服务阶段：随着PC互联网兴起，淘宝、QQ、Google、新浪这些全新的互联网服务逐步进入了我们的日常生活。 社会基础设施阶段：随着移动互联网、IOT、人工智能的出现和高速发展，各种各样的软件进入社会经济生活的方方面面，软件之间相互连接，构成了一个纷繁复杂的生态系统，变成了不可或缺的社会基础设施。 随着软件形态的变化，过去非常高效的系统架构和组织形态遇到了全面的挑战。因为我们所处的环境已经从量变到质变，突破临界点，产生了本质的不同。 阿里巴巴就是这个过程中的典型代表。从过去单一的电商业务演变成了复杂的经济体，没有了确定性的业务边界，蓬勃发展的…

Read More Read More

Scroll Up