故障，是每个技术人都不愿遇到，但却总会遇到的事件。程序Bug、安全漏洞、黑客攻击、服务器宕机、网络中断等诸多因素都有可能引发系统故障，使我们的业务面临瘫痪的窘境。这样的例子，国内外都在不断的发生，比如： 2020年，由于严重的全澳性IT故障，Coles的收银机全部不能联网，down机瘫痪。收银员扫不了货品顾客也不能结账，澳洲每家Coles超市都被迫暂时关闭。 2018年，上海的医疗保险信息系统就突发故障，波及上海各大医院的结算系统，致使大量市民在就医时无法正常使用医保卡，众多医院的排队窗口前纷纷大排长龙，场面混乱。事发之后就有不少网友质疑，涉及面如此之广的医保信息系统，“难道没有应急措施？” 这些活生生的真实案例都在提醒我们，技术赋能业务产生更高效率、获取更多价值的同时，保障系统稳定运行也至关重要。一旦系统出现大范围、长时间故障，致使业务中断的后果可能直接磨灭技术赋能带来的收益，甚至还可能带来经济损失、品牌受损等严重后果。
关于SaaS和Serverless，相信关注我的很多读者都已经不陌生，所以这篇不会聊它们的技术细节，而将重点放在SaaS软件架构中引入Serverless之后，能给我们的SaaS软件带来多大的收益。
在开始下面的内容之前，不妨先给自己半分钟时间，思考下：你认为Serverless的引入，对你现有的SaaS软件架构带来多大的提升？
先说一个大部分人都可以想到的：从Serverless简化运维的角度去思考，站在软件平台的运维方，能够降低运维复杂度。这个收益显而易见，我开始也只想到了这一点，直到这几天看了AWS re:Invent中几个关于SaaS架构与Serverless的演讲，才有了一些更高维度的思考。
资源服务器到底是什么以及怎么用很少有教程来专门聊这个东西，今天我们先来聊一聊这个概念，为后续的使用打一打基础。
在Spring Security干货系列教程中，我们一步步来学习了Spring Security的使用。其中大部分涉及到的都是传统的保护应用的方式。我们通过用户名和密码（也可以是验证码）来获得服务器给的凭证（JWT是其中的一种），然后携带凭证去请求接口以获得对应的资源（Resource）。绝大部分的单体应用使用这种模式非常方便和简单。
但是一旦你所在的项目做大了，需要改造成微服务了，使用这种方式就显得有些笨重了，每个服务的资源都需要认证授权，所以需要一种范式来简化这一流程。
近几年，微服务架构一直是热点之一，并且被公认为是 IT 软件架构的未来方向。
它是一种灵活的演进式架构，可以提升企业研发效能，同时赋能业务快速创新，目前众多企业应用微服务化，其中包括阿里、Netflix 等。我相信，企业应用微服务化是必然趋势，微服务人才的需求也会越来越高。
微服务架构落地实施的技术门槛会比较高，它需要基础平台的支撑，包括服务发现，路由，配置，安全和监控等等。这也是现在很多企业面临的困境，有业务微服务改造的需求，但技术人员大都欠缺相关技术经验，无法实施落地。
之前因为在做顾问与咨询的时候，见到了一种关于API网关和注册中心的错误用法。在我的星球里分享了一下这个案例，没想到最近又碰到了两个类似的案例。也许这样的问题还存在不少团队的应用中，所以再拿出来分享一下，希望可以帮助读者更好的理解注册中心与API网关的作用，并将它们用对地方！
在微服务架构中，我们都会使用API网关来作为暴露服务的唯一出口。这样可以讲与业务无关的各项控制，集中的在API网关中进行统一管理，从而使得业务服务可以更加专注于业务领域本身。
昨晚睡觉前，顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”，顺藤摸瓜看了一下之前的聊天记录，由于内容骂骂咧咧，我就不贴出来了。。。大致内容就是某公司在做微服务改造，但改的不伦不类，形式上像微服务，而本质上依然是单体，甚至连单体都不如。
这样的改造现象，其实在国内还是蛮多见的。下面就来聊聊这个有趣的话题：分布式单体。各位看官，看看你们公司是不是也犯了这样的错误？
先思考一个问题：从单体改造到微服务的时候，你们是不是按这样的步骤来的？
Java微服务能像Go微服务一样快吗？
这是我最近一直在思索地一个问题。
去年8月份的the Oracle Groundbreakers Tour 2020 LATAM大会上，Mark Nelson和Peter Nagy就对此做过一系列基础的的测试用以比较。接下来就给大家介绍下。
在程序员圈子里，普遍的看法是Java老、慢、无聊 ，而Go是快、新、酷
为了尽可能的进行一个相对公平的测试，他们使用了一个非常简单的微服务，没有外部依赖关系（比如数据库），代码路径非常短（只是操纵字符串），使用了小型的、轻量级的框架（Helidon for Java和Go工具包for Go），试验了不同版本的Java和不同的jvm。
每个人或多或少总会碰到要使用并且自己完成编写一个最基础的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.
— Jake Wharton (@JakeWharton)
December 2, 2020
混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。
大规模分布式软件系统的发展正在改变软件工程。作为一个行业，我们很快采用了提高开发灵活性和部署速度的实践。紧随着这些优点的一个迫切问题是：我们对投入生产的复杂系统有多少信心？
即使分布式系统中的所有单个服务都正常运行, 这些服务之间的交互也会导致不可预知的结果。 这些不可预知的结果, 由影响生产环境的罕见且破坏性的事件复合而成，令这些分布式系统存在内在的混沌。
我们需要在异常行为出现之前，在整个系统内找出这些弱点。这些弱点包括以下形式:
作为一名开发者，您在开发完自己的应用之后，是否有去了解过它是如何部署交付出去的吗？它们都是通过什么工具来完成这些工作的呢？ 如果您从来都没有思考过这个问题，每天重复着类似的CRUD业务实现。那么对于“持续交付”的知识是你跳出舒适区，往更高方向发展所必须学习的内容。 虽然持续交付本身与业务软件的实现没有多大关系，但是这对你理解技术架构与组织管理将会有着非常大的帮助。 最近读了博文视点刚出版的一本新书：《Java持续交付》，个人强烈推荐想要继续提升的Java开发者，基础架构和运维开发来读一下。
