架构运维

关于SaaS和Serverless,相信关注我的很多读者都已经不陌生,所以这篇不会聊它们的技术细节,而将重点放在SaaS软件架构中引入Serverless之后,能给我们的SaaS软件带来多大的收益。 在开始下面的内容之前,不妨先给自己半分钟时间,思考下:你认为Serverless的引入,对你现有的SaaS软件架构带来多大的提升? 先说一个大部分人都可以想到的:从Serverless简化运维的角度去思考,站在软件平台的运维方,能够降低运维复杂度。这个收益显而易见,我开始也只想到了这一点,直到这几天看了AWS re:Invent中几个关于SaaS架构与Serverless的演讲,才有了一些更高维度的思考。 下面我们就来一起看看在SaaS遇到Serverless,可以迸出怎么样的火花。 背景SaaS软件和Serverless服务,在国内的发展,一直有种难兄难弟的感觉。虽然做的事情不一样,...

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

为什么选择微服务架构?近几年,微服务架构一直是热点之一,并且被公认为是 IT 软件架构的未来方向。 它是一种灵活的演进式架构,可以提升企业研发效能,同时赋能业务快速创新,目前众多企业应用微服务化,其中包括阿里、Netflix 等。我相信,企业应用微服务化是必然趋势,微服务人才的需求也会越来越高。 微服务架构难?难于上青天?微服务架构落地实施的技术门槛会比较高,它需要基础平台的支撑,包括服务发现,路由,配置,安全和监控等等。这也是现在很多企业面临的困境,有业务微服务改造的需求,但技术人员大都欠缺相关技术经验,无法实施落地。 在我看来,造成这种困惑的主要原因,是缺乏端到端的贴近生产的微服务应用案例。 这里,推荐给你一个叫 Staffjoy 的开源项目,开发了教学版的微服务案例项目。整个项目采用微服务架构,并且可以一键部署到 Kubernetes 容器云环境。 直达 Staffjoy 教学...

之前因为在做顾问与咨询的时候,见到了一种关于API网关和注册中心的错误用法。在我的星球里分享了一下这个案例,没想到最近又碰到了两个类似的案例。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与API网关的作用,并将它们用对地方! 在微服务架构中,我们都会使用API网关来作为暴露服务的唯一出口。这样可以讲与业务无关的各项控制,集中的在API网关中进行统一管理,从而使得业务服务可以更加专注于业务领域本身。 而在微服务构建的系统内部,各个服务之间的调度,我们通常采用注册中心和客户端负载均衡的方式来治理服务之间的调用。 所以,大致的结构是这样子的: 关于注册中心和API网关的功能,主要有以下两点: API网关通过注册中心发现所有后端服务,从来实现动态代理 后端服务集群间,通过注册中心互相发现对方,而实现直接调用 下面就具体说说这个常见的错误...

昨晚睡觉前,顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”,顺藤摸瓜看了一下之前的聊天记录,由于内容骂骂咧咧,我就不贴出来了。。。大致内容就是某公司在做微服务改造,但改的不伦不类,形式上像微服务,而本质上依然是单体,甚至连单体都不如。 这样的改造现象,其实在国内还是蛮多见的。下面就来聊聊这个有趣的话题:分布式单体。各位看官,看看你们公司是不是也犯了这样的错误? 分布式单体为什么不好先思考一个问题:从单体改造到微服务的时候,你们是不是按这样的步骤来的? 确定业务领域,拆分存储,定义各微服务的边界 改造代码逻辑,将原来的内部service调用改成dubbo或feign这样的远程调用 通过这样的改造,我们得到了很多好处,比如: 代码库分开了,减少了麻烦的解决代码冲突的困扰 CI/CD分开了,每个拆分后的服务都可以独立开发、部署、运行 数据库分开了,独立运行,不同业务...

前言Java微服务能像Go微服务一样快吗? 这是我最近一直在思索地一个问题。 去年8月份的the Oracle Groundbreakers Tour 2020 LATAM大会上,Mark Nelson和Peter Nagy就对此做过一系列基础的的测试用以比较。接下来就给大家介绍下。 在程序员圈子里,普遍的看法是Java老、慢、无聊 ,而Go是快、新、酷 为了尽可能的进行一个相对公平的测试,他们使用了一个非常简单的微服务,没有外部依赖关系(比如数据库),代码路径非常短(只是操纵字符串),使用了小型的、轻量级的框架(Helidon for Java和Go工具包for Go),试验了不同版本的Java和不同的jvm。 对决双雄我们先来看下擂台两边的选手: 身穿深色战服的选手是JAVA Java是由被甲骨文收购的Sun Microsystems开发的。它的1.0版本是1996年发布的...

每个人或多或少总会碰到要使用并且自己完成编写一个最基础的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介绍: 从说明中,可以知道这是一个后端项目的大仓库,每个业务线都通过文...

从2016年起就开始接触Consul,使用的主要目的就是做服务发现,后来逐步应用于生产环境,并总结了少许使用经验。最开始使用Consul的人不多,为了方便交流创建了一个QQ群(群号在最后),这两年微服务越来越火,使用Consul的人也越来越多,目前群里已有400多人,经常有人问一些问题,比如: 服务注册到节点后,其他节点为什么没有同步? Client是干什么的?(Client有什么作用?) 能不能直接注册到Server?(是否只有Server节点就够了?) 服务信息是保存在哪里的? 如果节点挂了健康检查能不能转移到别的节点? 有些人可能对服务注册和发现还没有概念,有些人可能使用过其它服务发现的工具,比如zookeeper,etcd,会有一些先入为主的经验。这篇文章将结合Consul的官方文档和自己的实际经验,谈一下Consul做服务发现的方式,文中尽量不依赖具体的框架和开发语言,...

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

随着微服务架构风格的流行,组织内部不可避免的产生了许多小规模团队,原来一个几十上百人的产品团队被拆分成了类似Amazon这样的2 pizza(6~10人)小团队。组织结构上也由之前的层级化职能团队设置变成了扁平的小团队集群。每个做这样调整的企业都希望借助小团队的灵活性在这个科技时代跟上市场变化和创新的脚步。 当然这样的组织方式本身就带来了一系列的挑战,技术实践方面Martin Fowler已经通过微服务的定义文章做了很形象的叙述,还用了“你必须长这么高”(You must be this tall!)来比喻在技术实践方面所需做出的投入。 在组织管理方面,越来越多的挑战被识别出来,把“自组织”当做银弹来回答这样集群小团队组织和管理中的问题是行业里存在的一个不好趋势。在最近和Matin Fowler的讨论中,我们达成共识的一点是:与其说微服务是一种技术架构,还不如说是一种企业组织架构。...

本文转载自微信公众号「工匠小猪猪的技术世界」 主流数据库连接池常用的主流开源数据库连接池有C3P0、DBCP、Tomcat Jdbc Pool、BoneCP、Druid等 C3p0: 开源的JDBC连接池,实现了数据源和JNDI绑定,支持JDBC3规范和JDBC2的标准扩展。目前使用它的开源项目有Hibernate、Spring等。单线程,性能较差,适用于小型系统,代码600KB左右。 DBCP (Database Connection Pool):由Apache开发的一个Java数据库连接池项目, Jakarta commons-pool对象池机制,Tomcat使用的连接池组件就是DBCP。单独使用dbcp需要3个包:common-dbcp.jar,common-pool.jar,common-collections.jar,预先将数据库连接放在内存中,应用程序需要建立数据库连...

最近经常在项目或是社区里听到大家谈论微服务架构,但谈论的焦点更多集中在微服务拆分,分布式架构,微服务门槛,DevOps配套设施等话题上。 但是在我眼里,真正能称之为微服务架构的少之又少。原因也很简单,我所见到的很多所谓的微服务架构项目,大多都没有做到微服务架构的一个基本要求:服务的独立部署(交付)。 这里的独立部署和自动化部署还不是一个概念,服务的自动化部署相对简单,已有大量的工具可以帮助我们做到。但是这里所谈的独立部署,我认为关键和难点并不在于“部署”,而在于“独立”。 如果失去了服务独立部署(交付)的能力,一个微服务架构的威力将大打折扣,我们的系统虽然在物理上被拆分成了多个小的服务,但是如果从最终交付的角度来看,仍然是以一个整体存在的,就像单体应用一样,存在诸多的问题。 为什么服务的独立交付并不简单?那为什么不能让每一个服务都独立部署到产品环境呢?问题的答案是:不是不能,而是不...