Mobabel Blog

0

[总结]理解HTTPS

摘要:本文尝试一步步还原HTTPS的设计过程,以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时,你可以尝试放下已有的对HTTPS的理解,这样更利于“还原”过程。 我们先不了聊HTTP,HTTPS,我们先从一个聊天软件说起,我们要实现A能发一个hello消息给B: 如果我们要实现这个聊天软件,本文只考虑安全性问题,要实现: A发给B的hello消息包,即使被中间人拦截到了,也无法得知消息的内容 1.

0

[转]如何用女朋友能懂的方式解释Kubernetes

Kubernetes 有自己的各种模型和术语,导致很多初学者在刚刚接触 Kubernetes 时,理解起来有很多的困难和障碍。本文将其类比为主题公园,配合生动形象的图片,通俗易懂地阐述了 Kubernetes 的基础理念和各个组成部分。下次就可以这样给女朋友解释Kubernetes了 如果你是个技术工作者,你肯定使用或者听说过 Kubernetes。Kubernetes(后文简称为 k8s)有自己的一套抽象机制和术语,但是借助一些想象力,可以将这些抽象与我们更加熟悉的概念联系起来。这里我们将 k8s 类比为主题公园,下次你可以这么跟女朋友解释 k8s。 如下的内容都是基于谷歌 Kubernetes 引擎的,在其他的供应商中或者如果你自行运行 k8s 的话,有些概念可能会略有差异。

0

[转]如何运用 DDD 解决团队协作与沟通问题?

领域驱动设计的核心是“领域”,因此要运用领域驱动设计,从一开始就要让团队走到正确的点上。当我们组建好了团队之后,应该从哪里开始?不是UI原型设计,不是架构设计,不是设计数据库,这些事情重要却非最高优先级。 试想,项目已经启动,团队却并不了解整个系统的目标和范围,未对系统的领域需求达成共识,那么项目开发的航向会否随着时间推移而逐渐偏离?

0

[转]哪个技术火就选哪个?热闹驱动开发的技术选型使不得!

本文的主题是技术选型,作者总结了他见过的各种不靠谱的技术选型方式,比如有的团队会根据社交媒体上的讨论来决定选择哪种架构,也有的团队会跟风走,哪个热门就选哪个。但总体来看,这样简单粗暴的方式一定会为未来埋下隐患。那为什么这样说?我们应该如何做正确的选择?且听作者细细道来。另本文译者余晟,曾经是主力程序员、技术文章的写作和翻译爱好者,现在在沪江负责研发和软件架构。欢迎关注他的个人公众号“余晟以为”,了解一位非典型 IT 人员对世界的看法。 软件开发团队所做的软件架构或技术栈的决策,很多并没有经过踏实的研究和对目标成果的认真思考,而是不准确的意见、社交媒体的信息,或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发(Hype Driven Development,HDD)”,眼见它的危害,我赞成更专业的做法,就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉,想想能如何改进。

0

[转]金丝雀发布、滚动发布、蓝绿发布到底有什么差别?

根据 2017 年的 DevOps 发展报告,高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力,涉及众多环节,其中发布是尤为重要的环节。 作为技术人员,大家可能听说过“滚动发布”和“蓝绿发布”等术语,但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略,每个的优劣,适用性,让开发人员特别是架构师对现代发布技术有一个更为清晰全面的认识,让大家能够根据自己的企业上下文,对发布策略做出正确的选型和实践。

[转]app拆分,多产品打包实录 0

[转]app拆分,多产品打包实录

1. 1前言 公司有需求app需要拆分为两个:云部署版和企业版。 a.云部署版就是原app ,保持不变; b.企业版是新app,与云部署的界面,功能有差异,并且不上架应用市场,只在企业内网使用。用户手机上可以同时安装这两个app。 1-1-1-1.

0

[转]聊聊Chaos Engineering的历史、原则和最佳实践

  随着微服务和分布式云架构的崛起,Web 变得日趋复杂,“随机性”的故障因此变得越来越难以预测,而我们对这些系统的依赖却与日俱增。 这些故障给公司造成巨大损失,也给用户带来很大的麻烦,影响他们进行在线购物、交易或打断他们的工作。即使是一些简单的故障也会触及公司的底线,因此,宕机时间就成为很多工程团队的 KPI。2017 年,有 98% 的企业表示,一小时的宕机时间将给他们带来超过 10 万美元的损失。一次服务中断有可能让一个公司损失数百万美元。最近,英国航空的 CEO 透露,2017 年 5 月发生的一次技术故障造成数千名乘客滞留机场,给公司造成 8000 万英镑的损失。 企业需要想办法解决这些问题,因为等到下一次事故发生就为时已晚。为此,混沌工程(Chaos Engineering)应运而生。 混沌工程(Chaos Engineering)旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试系统在各种压力下的行为,识别并修复故障问题,避免造成严重后果。 混沌工程将预想的事情与实际发生的事情进行对比,通过“有意识地搞破坏”来提升系统的弹性。 1. 混沌工程简史 混沌工程最先出现在互联网巨头公司中,这些公司拥有大规模的分布式系统,因为这些系统太过复杂,他们需要一些新的手段来测试它们。 2010 年 Netflix Eng Tools 团队开发出了 Chaos Monkey。当时,Netflix 从物理基础设施迁移到...

[总结]58到家MySQL军规升级版 0

[总结]58到家MySQL军规升级版

1. 一、基础规范 表存储引擎必须使用InnoDB   表字符集默认使用utf8,必要时候使用utf8mb4 解读: (1)通用,无乱码风险,汉字3字节,英文1字节 (2)utf8mb4是utf8的超集,有存储4字节例如表情符号时,使用它