架构运维

资源服务器到底是什么以及怎么用很少有教程来专门聊这个东西,今天我们先来聊一聊这个概念,为后续的使用打一打基础。 传统安全方式的不足在Spring Security干货系列教程中,我们一步步来学习了Spring Security的使用。其中大部分涉及到的都是传统的保护应用的方式。我们通过用户名和密码(也可以是验证码)来获得服务器给的凭证(JWT是其中的一种),然后携带凭证去请求接口以获得对应的资源(Resource)。绝大部分的单体应用使用这种模式非常方便和简单。 但是一旦你所在的项目做大了,需要改造成微服务了,使用这种方式就显得有些笨重了,每个服务的资源都需要认证授权,所以需要一种范式来简化这一流程。 认证和授权是可以松耦合的用户的认证和资源的访问控制其实是可以分开的。就比如你买飞机票,现在你不仅可以在航空公司的售票部门买到票,也可以到第三方票务中心线下或者线上去买票,最终每个架次的...

每个人或多或少总会碰到要使用并且自己完成编写一个最基础的Bash脚本的情况。真实情况是,没有人会说“哇哦,我喜欢写这些脚本”。所以这也是为什么很少有人在写的时候专注在这些脚本上。 我本身也不是一个Bash脚本专家,但是我会在本文中跟你展示一个最基础最简单的安全脚本模板,会让你写的Bash脚本更加安全实用,你掌握了之后肯定会受益匪浅。 为什么要写Bash脚本其实关于Bash脚本最好的解释如下: The opposite of “it’s like riding a bike” is “it’s like programming in bash”. A phrase which means that no matter how many times you do something, you will have to re-learn it every single time. — J...

混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。 大规模分布式软件系统的发展正在改变软件工程。作为一个行业,我们很快采用了提高开发灵活性和部署速度的实践。紧随着这些优点的一个迫切问题是:我们对投入生产的复杂系统有多少信心? 即使分布式系统中的所有单个服务都正常运行, 这些服务之间的交互也会导致不可预知的结果。 这些不可预知的结果, 由影响生产环境的罕见且破坏性的事件复合而成,令这些分布式系统存在内在的混沌。 我们需要在异常行为出现之前,在整个系统内找出这些弱点。这些弱点包括以下形式: 当服务不可用时的不正确回滚设置; 不当的超时设置导致的重试风暴; 由于下游依赖的流量过载导致的服务中断; 单点故障时的级联失败等。 我们必须主动的发现这些重要的弱点,在这些弱点通过生产环境暴露给我们的用户之前。我们需要一种方法来管理这些系统固有的混沌...

作为一名开发者,您在开发完自己的应用之后,是否有去了解过它是如何部署交付出去的吗?它们都是通过什么工具来完成这些工作的呢?如果您从来都没有思考过这个问题,每天重复着类似的CRUD业务实现。那么对于“持续交付”的知识是你跳出舒适区,往更高方向发展所必须学习的内容。虽然持续交付本身与业务软件的实现没有多大关系,但是这对你理解技术架构与组织管理将会有着非常大的帮助。最近读了博文视点刚出版的一本新书:《Java持续交付》,个人强烈推荐想要继续提升的Java开发者,基础架构和运维开发来读一下。 为什么推荐?可能有的人会说,持续交付不是就是Jenkins、Gitlab CI这些么,官方文档撸一撸不就搞定了? 如果您是这么觉得的话,我会特别希望你可以读一下这本书。因为在持续交付过程中,这些工具还只是高质量持续交付过程中的冰山一角。在如今这个时代,从编程语言、部署平台、通讯方式等等方面,都是百花齐放...

先声明一下,本文不聊ISSUE中的七七八八,也不聊代码是否写的好,更不聊是不是跟蔡徐坤有关之类的吃瓜内容。仅站在技术人的角度,从这次的代码泄露事件,聊聊在代码的安全管理上,通常都需要做哪些事来预防此类事件的发生。同时,大家在阅读本文的时候,也可以深入思考下,自己团队是否也存在类似的问题,经过这次的事件,是否有必要针对性的做一些优化。 最小权限“最小权限”原则是我们在学习Linux用户管理时候经常被提到,并且被反复强调的内容。该原则是指每个程序和系统用户都应该具有完成任务所必需的最小权限集合。赋予每一个合法动作最小的权限,就是为了保护数据以及功能避免受到错误或者恶意行为的破坏。 在代码的安全管理上,“最小权限”原则同样适用。但是,从此次的代码泄露内容中可以看到,这一点做的并不好,一起来看看源自泄露代码的README介绍: 从说明中,可以知道这是一个后端项目的大仓库,每个业务线都通过文...

注:本文要求读者对Ansible和 Jenkins有一定的认识。 题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸 行业内各巨头的自动化运维架构都各种功能各种酷炫,如下图,让人可望不可及。现在最终的样子大家都知道了,但问题是如何根据自己团队当前的情况一步步向那个目标演进? 笔者所在团队,三个半开发,要维护几十台云机器,部署了十来个应用,这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发,测试通过后,再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道,更不用说配置中心及配置版本化了。 对了,连基本的机器级别的基础监控都没有。 我平时的工作是 50% 业务开发,50% 运维。面对这么多问题,我就想啊,如何在低成本情况下实现自动化运维。本文就是总结我在这方面一些经验和实践。希望对读者有帮助。 别说话...

编者按Google和Netflix联合发布了全新的开源Canary分析工具Kayenta。Canary(金丝雀部署)是现代Devops和持续交付中重要的一环,指的是把少量(通常1%-3%)的流量导到含有新版本的canary部署上运行一段时间并和当前的生产环境比较,再决定是否将新版本部署到所有机器的过程。转载请注明出处和原文链接。以下是项目代码: github.com/spinnaker/kayenta 为了成规模的实现持续交付,你不仅需要快速地发布软件更新,更需要能安全地发布。今天,Google和Netflix很高兴的发布Kayenta,一款开源的自动化Canary分析服务,该服务能让团队降低高速发布新部署时的相关风险。 由Google和Netflix联合开发的Kayenta是由Netflix内部的Canary系统进化而来,然后重新定义得完全开放,可扩展而且可以处理更多高级的用户...

将应用程序部署到 Kubernetes 时,有很多选择。像 Helm 和 Ksonnet 这样的工具使得打包应用程序并将其部署到多个 Kubernetes 环境变得非常简单。但是,这些工具只能解决部分问题。部署到生产很少像 helm install my-chart 一样如此简单。他们可以涉及多个步骤,并保证所涉及的应用程序正常运行。我从 Kubernetes 用户那里听到的一个最常见的问题是“如何部署我的数据库变更?”。这是我一遍又一遍地问自己的问题。在 Skuid ,我们花了很多时间试图找出最安全和高可用的方式来执行这些数据库迁移,作为我们部署 Pipeline 的一部分。我们写的代码来做到这一小步在我们的 Pipeline 步骤是很复杂的。 使用 Spinnaker,我们能够使这一步骤可重复,安全和可靠。在本教程中,我将解释如何设置一个简单的部署 Pipeline 来运行我们...

Spinnaker 的介绍 Spinnaker 是 Netflix 开源出来的持续交付工具,目的是为研发团队提供灵活的持续交付流水线,并且支持部署到测试/生产环境。Netflix 目前通过 Spinnaker 实现每天4000次的发布。它的优势在于: 支持多种云平台。目前支持 AWS EC2(Netflix 的机器大部分都在亚马逊),谷歌云,Kubernetes,Azure,Openstack 等,目前正在支持甲骨文的物理机和 DC/OS。 自动化发布。可以集成测试脚本进行测试,并且能够管理测试,线上环境的机器,实现动态扩容,和服务的下线。 发布原子化。由于 Netflix 的平台已经实现微服务化,每个团队使用 Spinnaker 独立维护服务的发布,所以 Spinnaker 的设计特别适合于微服务持续交付的场景。 预置了软件发布的最佳实践。通过脚本实现不可变基础设施,使得发布时候...

Jenkins Pipeline 插件对于 Jenkins 用户来说可以让用户能够改变游戏规则。基于 Groovy 中的领域特定语言(DSL),Pipeline 插件使 Pipelines 可以有脚本来定义,并且提供了非常强大的方法来开发复杂的、多步 DevOps Pipeline 。本文记录了编写 Jenkins Pipeline 的一些的最佳实践和不推荐的代码示例和说明。 1. 要使用真正的 Jenkins Pipeline不要使用像 Build Pipeline 插件或者 Buildflow 插件这样的旧插件。而是使用真正的 Jenkins Pipiline 插件套装。 这是因为 Pipeline 插件是底层工作自身的一个改变和提升的 Step。与 Freestyle 任务不同,Pipeline 对 Jenkins 主机重新启动具有适应能力,并且有可以替代以前用于构建多步、...

前文导读:《都在说微服务,那么微服务的反模式和陷阱是什么(一)》《都在说微服务,那么微服务的反模式和陷阱是什么(二)》 九、通信协议使用的陷阱在微服务架构体系中要求每个服务都是独立布署,这就意味着服务之间会有通信,也就是说会有很多的远程访问。 当你不知道这些远程访问需要多长时间的时候,就会掉入到这个陷阱,当然我们可以假定远程访问一次50毫秒,但我们是否真正的进行过测试呢?那么服务的平均响应时间是多少呢?即使有看上去很好的平均响应时间,那么糟糕的“长尾延迟”也会将整体系统摧毁。 9.1 延迟测量在生产环境中进行压力测试,是检测我们系统性能的重要手段之一,举个例子:我们有一个特定业务需要四个服务来协调处理,假如远程访问一次的时间是100毫秒,那么这个特定业务就需要消耗500毫秒(初始请求+四个服务的调用时间),这个只是远程访问的时间,还不算实际业务代码的执行时间,这是大多数应用系统都...

上一篇:《都在说微服务,那么微服务的反模式和陷阱是什么(一)》 六、无因的开发者陷阱名字来自詹姆斯·迪恩演的电影《无因的反叛》(Rebel Without a Cause),一个问题青年因为错误的原因做了错误的决定。 很多架构师和开发者在微服务的开发中权衡利弊, 比如服务粒度和运维工具,但是基于错误的原因,做了错误的决定。 6.1 做出错误的决定图6-1说明了一种情况是通过测试发现服务划分的太细了,因此非常影响性能,主要是由于服务划分的太细导致增加了通信工作量也在一定程度上对稳定性造成一定影响。在这种情况下,开发人员或架构师决定将这些服务整合到一个更粗粒度的服务中,以解决性能和可靠性问题。 这个方案看起来似乎合情合理,但是之后的布署、更改控制和测试都会受到影响。 再看图6-2,这种场景是左边的服务太粗了,影响了服务的测试和布署,于是进行了拆分,减少了每个服务的范围。 通过以上...

一、数据驱动的迁移反模式微服务会创建大量小的、分布式的、单一用途的服务,每个服务拥有自己的数据。这种服务和数据耦合支持一个有界的上下文和一个无共享数据的架构,其中,每个服务及其对应的数据是独立一块,完全独立于所有其他服务。服务只暴露了一个明确的接口(服务契约)。有界的上下文可以允许开发者以最小的依赖快速轻松地开发,测试和部署。 采用数据驱动迁移反模式主要发生在当你从一个单体应用向微服务架构做迁移的时候。我们之所以称之为反模式主要原因是,刚开始我们觉得创建微服务是一个不错的主意,服务和相应的数据都独立成微服务,但这可能会将你带向一个错误的道路上,导致高风险、过剩成本和额外的迁移工作。 单体应用迁移到微服务架构有两个主要目标: 第一个目标是单体应用程序的功能分割成小的,单一用途的服务。 第二个目标是单体应用的数据迁移到每个服务自己独占的小数据库(或独立的服务)。 下图展示了一个典型的...

概述微服务架构是一种非常流行的新概念,即便可供以借鉴的经验比较少,当然不能阻挡它成为热门话题与研究对象。 令人惊讶地是,其实微服务的概念早在五十多年前就已经被提出,多年来,很久研究表明了这些观点的准确性。这就是本文所介绍的——康威定律。现在已经有很多企业正在尝试使用它创建高效的微服务架构。 在这篇文章中最有名的一句话莫过于: 设计系统的企业受限于生产设计,这些设计是企业沟通结构的副本——Melvin Conway(1967)。 这意味着设计系统的企业,它们生产的设计等同于企业内的沟通结构。下图说明了此概念: 该图展现了企业现有沟通结构,简单地说:企业结构等于系统设计。 作者这里提到的系统并不局限于应用系统,据说这篇文章最初投稿于哈佛商业评论,但被拒绝,因此康威将其提交到了一个编程杂志,所以被误解为只针对应用开发,起初,作者并没有把这种理论作为定律,只是描述了发现和结论,不过著名的...

DDD社区官网上一篇关于聚合设计的几个原则的简单讨论:文章地址:http://dddcommunity.org/library/vernon_2011/,该地址中包含了一篇关于介绍如何有效的设计聚合的一些原则,共3个pdf文件。该文章中指出了以下几个聚合设计的原则: 聚合是用来封装真正的不变性,而不是简单的将对象组合在一起; 聚合应尽量设计的小; 聚合之间的关联通过ID,而不是对象引用; 聚合内强一致性,聚合之间最终一致性; 上面这几条原则,作者通过一个例子来逐步阐述。下面我按照我的理解对每个原则做一个简单的描述。 聚合是用来封装真正的不变性,而不是简单的将对象组合在一起这个原则,就是强调聚合的真正用途除了封装我们本身所关心的信息外,最主要的目的是为了封装业务规则,保证数据的一致性。在我看来,这一点是设计聚合时最重要和最需要考虑的点;当我们在设计聚合时,要多想想当前聚合封装了哪些...