东境物语

在数字化时代，软件服务的稳定性至关重要。然而，即便是像网易云音乐这样的大型平台，也难免遇到突发的技术故障。8月19日下午，网易云音乐疑似出现服务器故障，网页端出现502 Bad Gateway 报错，且App也无法正常使用。这不仅严重影响了用户体验，还给公司带来声誉和经济损失。面对这类情况，开发团队该如何快速响应、高效解决问题，并从中吸取教训以防患未然？是否有一套行之有效的危机应对机制？又该如何在日常工作中培养团队应对突发事件的能力？让我们一起探讨如何在技术风暴中站稳脚跟，提升团队的应急处理能力吧！

此外，京东云还通过变更管控实践，建立变更全生命周期的管控系统，提高变更成功率，降低变更引发的故障率。在实际应用中，需要综合考虑系统的处理能力、业务需求和用户体验，选择最合适的限流算法，并合理配置限流参数，以有效防止流量激增导致系统崩溃。一个高可用的系统架构是系统稳定性的基础，只有在此基础上，才能进一步保障系统的稳定性和可靠性，为业务的顺利开展提供有力支撑。容器化、微服务架构和服务网格等技术使得系统的部署和管理更加灵活和高效，但同时也带来了新的挑战，如服务间的通信复杂性和分布式环境下的故障排查难度增加。

本文深入探讨了ElasticSearch（ES）的优化策略，旨在帮助读者提升搜索引擎的性能和效率。文章首先介绍了ES的数据写入和搜索的流程。随后，通过具体用例分析，展现了在不同业务场景下的优化实践，如新闻内容检索、客户服务记录检索和物流信息追踪平台。这些用例揭示了索引分片调整、热点数据处理、异步写入、内容分级索引等多种优化手段的实际效果。文章强调优化ES是一个持续的过程，需要不断地监控、调整和优化以应对数据增长和业务需求的变化。

传统的关系型数据库（RDBMS）以其严格的ACID事务、优秀的一致性和安全性在企业应用中占据了长久的统治地位。然而，随着互联网、大数据和云计算的兴起，非关系型数据库（NoSQL）因其灵活的数据模型、易于水平扩展的特性和优异的处理高并发请求的能力，在特定场景下得到广泛应用。此外，时间序列数据库（TSDB）、图数据库等针对特定类型的数据和查询提供了更加专业的解决方案。除此之外，新型数据库如向量数据库则为机器学习、人工智能和相似性搜索提供了更高效的整体解决方案。本文将探讨9种数据库，涉及各种数据库风格。

本文旨在探讨ES、HBase、Redis、MySQL和MongoDB这五种技术的核心特性和优势，通过分析它们在不同应用场景下的表现，为技术选型提供指导和建议。

本文主要涉及境外出行、商场团购和内容商业化等三类交易业务场景。在大众点评App里，在境外城市站有美食、购物、商场、景点、门票、当地玩乐等频道入口，可以购买境外出行交易产品，在境内的逛街/商场频道可以找到商场团购优惠以及商场团购代金券。此外，商家如果有推广需求可以在商家端App（开店宝App）“点星”入口购买达人的创作服务，最终达人交付的笔记，在点评App信息流里进行展示。具体来说，境外出行产品覆盖景点门票、餐厅订座和休闲娱乐；商场团购产品包含普通团单和秒杀团单，适用于商场的优惠活动；

高德打车是高德地图首创的“聚合打车”模式，一键全网叫车，轻松全网比价，让用户打车更快、更省；推出“好的出租”计划，帮助传统巡游出租车数字化升级，帮助出租车司机增加收入。高德打车在运力类型上有网约车、出租车、巡改网、城际拼车等；同时订单类型又有实时单、预约单、代叫单、接送机、市内拼车等；当然在车型和价格上也有一定区分。

滴滴是一家以出行为核心、辐射单车、代驾、车服、金融、国际化等领域的高速发展的科技公司，在各条业务线飞速发展的过程中会存在着很多相同或者类似的业务需求，如何通过技术的手段抽象、沉淀这些业务为通用、稳定基础能力，让各业务线专注于其个性化的部分，快速的推出适合市场的新产品，是业务中台核心价值的体现。滴滴业务中台已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力，高效率、低成本的支持了各条业务线的快速发展。何修峰，就职于滴滴业务中台，任高级技术专家一职，致力于。

云杉是中国最大的 ToB 生鲜电商美菜网的公司主体，云杉下包括美菜在内的各业务线的急速扩张和更深入的精细化运营，带来了更高的业务复杂度，之前的系统架构已经很难支撑目前多业务多平台的形态，部门的效率也因为系统耦合而大大下降。在业务发展的过程中遇到很多问题，不断的对业务流程和系统架构进行思考，尝试以中台化思维解决问题，并借着2018年底新电商业务线成立之时，推动公司建立中台团队，目前主要负责商品中心和交易中心的架构工作。对电商及周边体系的关系有一个更清晰的认识。对电商交易核心的理解，抓住问题的本质。

Salesforce可能是这个世界上最有名的To B领域的公司，市值2500亿美元，凭借着SaaS化的架构理念，并通过依此构建的CRM产品占据CRM 20%的市场，财富500强的公司中，有83%在使用它。公司雇员超过5万人，其业务范围包括财税管理软件、人力资源管理软件、进销存管理软件、客户管理软件、办公自动化软件、企业内即时交流软件等。1999年，Salesforce在美国旧金山成立2001年，推出第一款SaaS应用CRM，同时也受到众多厂商和客户的热议。

其实这是最重要的却常常被忽略，栽一棵树最好的时间是十年前，然后是现在，三年后平台的高可用做到什么级别取决于当下上层OKR对它的定位，最容易出现超大故障的时候，常常是自上而下业务非常自嗨的时候，有些高层甚至可能都瞧不起被他们类比成水泥匠的稳定性打工人，认为做好稳定性是应该的，做不好就得挨板子，在这种人浮于事的环境下，要把稳定性坚持做好，需要底下管理者和团队非常强的责任心和使命感，但永远不要忽略人性，再强的责任心也需要现实激励去喂养。故障越大，锅就越不是执行变革的一线同学的，为什么呢？

只有把稳定性当成业务的功能实现一样，有相应的人员配备和投入，例如做一个业务可能需要多少人，相应的稳定性这块也固定投入多少人，你说到底多少比例合理呢，其实也说不太清楚，但这种简单粗暴的方式其实是最有效的，当然，是不是要把稳定性上升到这样的高度，也需要根据业务的性质、业务所处的阶段来具体判断，以及有这样的投入的情况下，怎么去评判相应职责的团队也仍然是个很复杂的话题。很多做过稳定性这事的人都知道，做这个事情最麻烦的是很难被认可，做的好，不出问题，不懂的人不知道你做了什么，出了问题的时候觉得你到底做了什么，

在交易日均千万订单背景下，如何保障订单数据基座高扩展、高可用、高吞吐？

在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。有幸，我曾经深度参与过一个中等互联网公司，建设异地多活系统的设计与实施过程。所以今天，我就来和你聊一聊异地多活背后的的实现原理。认真读完这篇文章，我相信你会对异地多活架构，有更加深刻的理解。

我们可以简单的做一些对比，主要在于硬件成本和软件性能的对比。从上文可知，磁盘的占用原始方案占用了磁盘（1 份），MQ（2 份），数据库（1 份）。而在新的方案中，磁盘的占用仅剩下 clickhouse 的（0.8 份），clickhouse 自身又对数据做了压缩，实际占用空间不到入库容量的 80%。那么仅磁盘即可节省 75% 以上的存储成本。大家都知道，秒级的吞吐量，是伴随着服务器 Cpu 的耗费的，并不是说只给个大硬盘，即可一台服务器每秒吞吐 1 个 G 的。

首先定义下什么是交易履约，交易履约是在甲乙双方达成交易产生订单后，乙方按照订单条款为甲方提供服务或交付约定物的行为。

你知道SaaS，iass 和pass之间的区别吗

JDEasyFlow是京东企业金融研发部自研的通用流程编排技术组件，适用于服务编排、工作流、审批流等场景，该组件已开源(https://github.com/JDEasyFlow/jd-easyflow)，目前在部门的内部业务系统和科技输出系统中广泛应用，其他部门也有使用。

系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。为了方便，本文阐述的系统主要指软件系统。那么如何衡量系统稳定性的高与低呢？一个常用的指标就是服务可用时长占比，占比越高说明系统稳定性也越高，如果我们拿一整年的数据来看，常见的 4 个 9（99.99%）意味着我们系统提供的服务全年的不可用时长只有 52 分钟！它其实是一个综合指标，为什么这么说？因为我们在服务可用的定义上会有一些差别，常见的服务可用包括：服务无异常、服务响应时间低、服务有效（逻辑正确）、服务能正常触发 等。...

​Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。简单的说，有了Istio，你的服务就不再需要任何微服务开发框架（典型如Spring Cloud，Dubbo），也不再需要自己手动实现各种复杂的服务治理功能（很多是Spring Cloud和Dubbo也不能提供的，需要自己动手）。只要服务的客户端和服务端可以进行简单的直接网络访问，就可以通过将网络层委托Istio，从而获得一系列的完备功能。......

一、架构演进剖析1、架构演进定义【定义】通过设计新的系统架构(4R)来应对业务和技术的发展变化。【目的】1. 应对业务发展带来新的复杂度;2. 应用技术发展带来的复杂度新的解决方法。【关键】1. 新架构;2. 新的复杂度;3. 新的方法。2、架构重构 vs 架构演进3、架构演进的原则、驱动力和模式二、业务驱动的架构演进技巧1、架构演进模式 vs 业务发展模式2、不同用户规模的架构挑战3、业务驱动的主动演进技巧 - 做好...

导语近些年单元化架构在构建多地数据中心，以及如何应对海量请求高并发、低延时的场景中被频繁提及和讨论。单元化架构其实主要解决的是系统扩容、多数据中心容灾、异地访问等方面出现的问题，本文将从单元化概念及优劣势、如何基于TSF建设单元化架构、某国有大行的单元化落地实践三方面进行分享。认识单元化1. 单元化是怎么来的呢？系统架构在前中期的快速发展阶段，往往更多的是考虑如何快速上线，中台如何支撑更多的系统。但单个机房整体的资源利用率总会存在上限，即使各种技术优化手段再有效，也很难有明显提升，那么单一机

导读：本文主要介绍了高德在服务单元化建设方面的一些实践经验，服务单元化建设面临很多共性问题，如请求路由、单元封闭、数据同步，有的有成熟方案可以借鉴和使用，但不同公司的业务不尽相同，要尽可能的结合业务特点，做相应的设计和处理。一、为什么要做单元化 单机房资源瓶颈 随着业务体量和服务用户群体的增长，单机房或同城双机房无法支持服务的持续扩容。 服务异地容灾 异地容灾已经成为核心服务的标配，有的服务虽然进行了多地多机房部署，但数据还是只在中心机房，实现真正意义上的异地多活..

在当今的互联网业内，很多大型互联网系统，比如淘宝、支付宝、网商银行等，都已经实现了单元化架构，并从中获益匪浅，更多企业正加入其中。为什么要做单元化，单元化架构能给系统带来什么样的能力。本文结合蚂蚁集团支付宝系统的单元化架构建设实践，阐释单元化的原理与实现。单点瓶颈任何一个互联网系统，不论是支付宝、淘宝，还是 Google、Facebook，当发展到一定规模时，都会不可避免地触及到单点瓶颈。这里所说的“单点”，在系统的不同发展阶段表现不同。服务器和应用单点在系统发展初期，服务器和应用单点最

一、前情提要时节如流，两年前的今天写了有赞订单管理的三生三世与十面埋伏，转眼两年过去了，这套架构发展的如何，遇到了什么新的挑战和收获，今天主要来一起整理回顾下有赞订单搜索AKF架构演进之路。1.1 分久必合之前将散落在 DB 多个分片中的数据在 ES 做了一次聚合，带来了巨大的好处，同步任务少，维护成本低。尤其是订单迁移这一块，之前由于是分片设计，所以当订单触发迁移时候，需要将数据插入新分片，确认无误后还需要删除老分片数据，流程繁琐易错，统一收拢后对于 ES 来说，各个端订单迁移，都只是一次更新

概述有赞搜索中台作为有赞企业级搜索能力复用平台，在解决各个业务域搜索问题时是如何探索与实践的，这个过程中有哪些心得，本文与大家一起分享探讨下。问题域跟绝大多数烟囱式架构面临的问题是相似的，业务自建搜索，独立选型往往会遇到以下问题：技术选型单一或跟风，比如公司有业务用 ES 做搜索，那我也用，而业务对实时性的要求，准确性的要求都是不一样的。 一致性保障困难，多数据源触发，并发场景下各自尝试的一致性保证方案，参差不齐，有的设计很重。 数据孤岛，领域意识加强后会使得系统间的业务串联变的困难..

前言导读　　当下企业软件应用开发面临着需求复杂多变、新的需求和系统不断增长，软件系统变得越来越复杂，普通的软件开发方式难以快速满足用户需求。为了解决这些问题，就出现了很多新的方法，其中最突出的一个就是模型驱动开发 MDD （Model Driven Development）。　　基于高度业务模型驱动开发MDD，通过使用高度抽象的领域业务模型作为构件，完成代码转换实现或各种模型驱动引擎配置支撑，降低开发成本，应对复杂需求变更。其基本思想是让开发中心从编程转移到高级别抽象中去，通过模型转成代码或其他构件

MDD模型驱动开发 Model Driven Development（MDD）是一种以模型作为主要工件的高级别抽象的开发方法，是 iuap 平台下的元数据驱动设计框架，前后端的统一基于元数据的架构。模型在工具的支持下，作为核心资产被转换成代码或者可运行配置，可以降低开发成本，应对复杂需求变更。MDD 开发框架，是用友云针对企业数字化中台理念实现的一套开发框架。从企业云服务核心问题域出发，总结提炼出最佳实践，且形成了统一的标准及规约。致力于支撑中台能力快速孵化，形成中台各能力间连接的纽带，最终实现中台

架构以及我理解中架构的本质在开始谈我对架构本质的理解之前，先谈谈自己的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上要重视它 ，战术上又要藐视它。先举个例子感受一下千万级到底是什么数量级？现在的优步(Uber)，从媒体公布的信息看，它每天接单量平均在百万左右，假如每天有10个小时的服务时间，平均QPS只有30左右。对于一个后台服务器，单机的平均QPS可以到达800-1000，单独看写的业务量很简单 。为什么我们又不能说轻视它？第一，我们看它的数据存储，

简述普通的哈希分库方式：hash(id) mod 数据库总数 = 目标数据库编号普通哈希分库做法这种传统的分库分表方式会遇到一个扩容问题：若要增加数据库数量，所有数据库中的数据都要重新分配一遍。例如本来系统有4台数据库， 现在要增加到5台数据库，这样本来id%4=0，存到第0台数据库的数据，现在全变成id%5=4，存到第4台数据库。为了解决这个扩容问题，引入了一种在扩容操作上成本更低，灵活度更高的算法一致性哈希分库方式：# 假设哈希空间为2...

什么是 AxonAxon Framework 通过支持开发人员应用命令查询责任隔离（CQRS）架构模式来帮助构建可扩展和可维护的应用程序。它通过提供最重要的构建块（例如聚合，存储库和事件总线（事件的分发机制））的实现来实现。此外 Axon 提供注释支持，它使您可以构建聚合和事件侦听器，而无需将代码与 Axon 特定的逻辑绑定在一起。这使您可以专注于业务逻辑而不是管道，并可以使您的代码更易于独立...

在常用的三层架构中，通常都是通过数据访问层来修改或者查询数据，一般修改和查询使用的是相同的实体。在一些业务逻辑简单的系统中可能没有什么问题，但是随着系统逻辑变得复杂，用户增多，这种设计就会出现一些性能问题。虽然在DB上可以做一些读写分离的设计，但在业务上如果在读写方面混合在一起的话，仍然会出现一些问题。本文介绍了命令查询职责分离模式(Command Query Responsibility S...

既然今天要聊一聊云原生时代的业务流程编排，那咱们首先得定义什么是流程编排以及传统的流程编排是做什么的。传统的流程编排一般分两类：bussiness process management（BPM 业务流程管理）和 workflow engine (工作流引擎)，在过去十几年里，商业领域主要是以BPM为主，软件服务厂商以平台化的产品为企业客户提供流程设计、流程管理、流程自动化相关的能力。BPM可以及时响应企业的组织架构、业务交互及运营模式的灵活多变，并且可以满足企业内部、企业与伙伴之间的业务交互需求。这一块

什么是流程编排？使用各种“能力”进行编排来完成某一业务，各个“能力”被有序的编织起来，聚合成一条特定的执行链。为什么要流程编排？为了解决各个BU对流程差异化的诉求，我们需要提供一种工具，可以根据能力自由组合，快速解决新的业务场景诉求，甚至可以让业务自己创建流程。比如电商场景里的交易流程：1、因为交易多种多样，比如买彩票，跟普通商品的交易流程不大一样，买彩票不需要物流。（虚拟商品交易）2、比如预付款交易，下单后先支付预付款，后续再支付尾款。3、组合商品交易跟普通单个商品交.

前言设计是把双刃剑，没有最好的，也没有更好的，而是条条大路到杭州。同时不设计和过度设计都是有问题的，恰到好处的设计才是我们追求的极致。DDD（Domain-Driven Design，领域驱动设计）只是一个流派，谈不上压倒性优势，更不是完美无缺。 我更想跟大家分享的是我们是否关注设计本身，不管什么流派的设计，有设计就是好的。从我看到的代码上来讲，阿里集团内部大部分代码都不属于 DDD 类型，有设计的也不多，更多的像“面条代码”，从端上一条线杀到数据库完成一个操作，仅有的一些设计集中在数据库上。我

基本概念：　　领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名：领域驱动设计—软件核心复杂性应对之道)一书。，书中提出了“领域驱动设计(简称 ddd)”的概念。 领域驱动设...

一、前言不论是哪种后台管理系统，“人员权限”始终是绕不开的话题。无论是移动端，PC端产品，登陆都需要一个账号。只是对于C端的产品，大多都是用户自己注册即可。而对于后台产品而言，是需要公司内部人员去创建账号的。每个使用系统的用户都有一个独一无二的账号，每个账号都有自己对应的权限。多数情况下，除了超级管理员外，我们会对大多数的账号的权限做一些限制，以此来管理不同用户的使用权限问题。譬如，做企业使用类软件，不同部门、不同职位的人的权限是不同的；再例如一款收费产品的收费用户和免费用户权限也是迥然不同

业务监控, 主要侧重对业务状态数据的实时监控, 收集数据后对业务数据进行深入的统计分析, 帮助业务方发现问题, 定位问题根源. 这其中数据分为: 业务自身输出的业务日志(比如: 提单, 推单, 接单等状态数据), 业务异常, 报警事件等.发现问题原因之后我们需要解决问题, 最终目的是可以基于我们分析的结果给运维动作做出决策, 以达到自动化运维的目的. 另外, 明确系统用户将有助于把控业务监控产品的设计方向, 业务监控系统的第一用户是RD, 不是老板, 我们是要帮助RD更快的发现问题, 预知问题, 提供标准化

美团外卖业务在互联网行业是非常独特的，不仅流程复杂——从用户下单、商家接单到配送员接单、交付，而且压力和流量在午、晚高峰时段非常集中。同时，外卖业务的增长非常迅猛，自2013年11月上线到最近峰值突破1600万，还不到4年。在这种情况下，一旦出现事故，单纯靠人工排查解决问题，存在较多的局限性。本文将详细解析问题发现、根因分析、问题解决等自动化运维体系的建设历程与相关设计原则。首先从业务本身具有的一些特点来讲一下自动化业务运维的必要性。业务流程复杂图1 用户角度的美团外卖技术体系美团外卖的

01淘宝交易订单系统介绍天猫和淘宝每天发生的实物和虚拟商品的交易达到亿级别。考虑到一次成功交易的整个链路，会涉及到会员信息验证，商品库信息查询，订单创建，库存扣减，优惠扣减，订单支付，物流信息更新，确认支付等。链路中的每一环都涉及到数据库中记录的创建和状态的更新，一次成功的交易可能对应到后台信息系统上数百次数据库事务操作，支撑交易系统的整个数据库集群则会承担每日高达数百亿的事务读写。这除了给数据库系统带来巨大的性能挑战之外，每日递增的海量数据也带来巨大的存储成本压力。交易订单作为其中最为关键的信