业务

近日，顶象收到“数字政府网络安全产业联盟”颁发的会员牌匾，标记着顶象正式成为该联盟会员，独特推动数字政府网络安全产业的衰弱倒退。 “数字政府网络安全产业联盟”由广东省政务服务数据管理局牵头发动成立，属全国性非盈利行业组织。聚焦数字政府网络安全将来的趋势和核心技术，将网络安全产、学、研、用贯通一体，紧密结合，一直推出政务网络安全和数据安全问题的最新、最优解决方案，加强抵挡内部网络攻击和防备外部违规操作的危险防控能力，进一步欠缺网络安全体系建设，晋升数字政府整体平安防护程度，致力于打造全国数字政府网络安全畛域最具影响力的技术创新平台、业务交流平台、凋谢共享平台和生态单干平台。 平安是数字政府建设的基石2023政府工作报告中提出了，继续推动政府职能转变，推动政务服务集成办理、一直优化大众办事服务，优化营商环境给经商办企业更多便当和空间。 数字政府通过提供数字化服务，反对数字技术创新，打造数字生态，反对数字经济的倒退。同时，政府数字化转型是数字中国建设的外围工作之一，通过优化政府外部业务流程，进步政府部门信息化程度，进步政府效率和服务质量。 数字政府市场分为基础设施层市场、平台层市场以及利用解决方案层市场，2022年整体市场规模达1372亿元人民币，市场规模微小。IDC 预测，在 “十四五” 布局和数字政府政策的疏导下，数字政府市场迎来重要倒退窗口期，整体市场到2025年将放弃绝对高速的增长，预计到2026年将达到2173亿元人民币的市场规模，复合增长率（CAGR）为12%。 平安是建设数字政府的基石。数字政府建设中必须同步发展平安保障重点工作，围绕数字政府建设因素，造成平安保障工作体系。 首先，数字政府买通各层级、各地区、各部门、各业务、各零碎的交换合作渠道，也相应带来了平安防护对象的多样性、边界的模糊性、范畴分割扩充性以及相干方的复杂性，推动平安预警协同共享，威逼情报实时互通，实现数字平安的实时响应。 其次，通过全方位网络危险监测剖析能力，被动摸索发现内外部平安危险，被动监测剖析平安异样行为，从而具备全链条的危险追踪与回溯能力，提供基于大数据的平安监测感知能力，实现持续性危险的发现、预警和响应，实现对数字业务的全流程态势感知。 最初，基于瞬息万变的危险挑战和多元化平安需要，构建一个笼罩多渠道全场景，提供多阶段防护的平安体系。该体系提供威逼感知、平安防护、数据积淀、模型建设、策略共享等平安服务，可能满足不同场景，领有丰盛策略且可能基于本身业务特点实现积淀和更迭演进，实现平台的精准防控，为数字政府持重倒退保驾护航。 顶象深耕数字政府平安建设2月底，顶象收到香港特区政府资讯科技总监办公室中标告诉。顶象无感验证中标GovHK香港政府一站通网站某数字化我的项目，将为该我的项目提供平安验证服务。三个月前的2022年12月，中国信通院“2022数字政府建设赋能打算整体（扩充）会议”上，颁布了第五批数字政府建设赋能打算成员单位和技术专家名单。其中，顶象入选“数字政府建设赋能打算成员单位”，顶象首席技术官张晓科荣获第五批政府建设赋能打算技术专家名称。 作为国内当先的业务平安公司，顶象始终在助力数字化政府建设。与中国信通院独特公布了《业务平安白皮书—数字业务危险与平安》系统地对业务平安危险的倒退态势和关键技术要求进行剖析，为企事业单位建设更齐备高效的业务平安能力体系提供策略领导；公布《人脸识别平安白皮书》，助力监管部门增强人脸平安危险的治理；公布《城市生产券平安调研报告》，揭发黑灰产牟利手法，助力政府增强对城市生产券发放的治理。助力保险公司反欺诈，为某保险公司挽回数千万的经济损失；助力航空公司反爬防虚伪占座，为某航空公司每年节俭千万元的查问开销；助力电商平台反欺诈，为某电商平台升高95%营销费用；为多个政务平台提供适老化计划，助力多个政务网站防备歹意爬虫。 截至目前，顶象已为交通部、商务部、教育部、最高法院、国税总局、市场监管总局等18家政府机构及银行、证券、保险、电力、出行、电商、运营商等24个行业3000多家企事业机构提供业余服务，充分证明了顶象在业务平安畛域的业余实力。将来，顶象通过前沿的技术手段、丰盛的教训和业余的服务能力，为政府和企业提供更全面、更优质的业务平安解决方案和服务，推动数字化政府建设倒退。 业务平安大讲堂：立刻报名 业务平安产品：收费试用 业务平安交换群：退出畅聊

疫情三年，近程办公、线上合作作为高频场景需要取得了疾速倒退。随着生产生存复原如常，政企的办公需要也进一步积淀。关注【融云 RongCloud】，理解协同办公平台更多干货。 作为业务倒退的根底，在业务线增多、组织层级重叠、业务信息积淀等因素推动下，政企办公平台的定位逐步从后盾撑持转向信息中枢，且须要满足政企本地化存储、个性化定制、业务交融、数据窃密等要求。 另一方面，落实党中央、国务院重大部署，踊跃推动数字化改革和数字政府建设，同时放慢部署推动企业数字化转型，全面实现国产化代替，是以后政企办公畛域的重大契机。在信创政策和政企外部信息系统沿革的独特推动下，政企办公需要正迎来新一轮增长。 依据《中国政企数智办公平台行业钻研报告》（后盾回复“办公”获完整版报告）预测，2023 年中国政企数智办公平台市场规模将达 108 亿，自 2021 年起以 20% 的复合增速持续增长。 ｜三大价值｜「百幄」系列产品助力政企数字化转型目前，很多政企的外部工作还停留在传统合作工具的模式上，工作音讯、外部告诉、公文流转以人工被动浏览、外部流程层层审批为主。因为业务零碎多、用户体系不健全，工作人员须要重复登录不同业务零碎进行日常办公，造成信息同步难、反馈不及时、覆盖面窄、工作效率低等问题。 随着政企外部办公业务多样化、挪动化、复杂化、智能化的需要逐渐降级，一套对立的、规范的、智能的、多渠道的综合办公平台是以后政企数字化改革的事不宜迟。 融云在十余年通信技术积淀和多年服务政企客户实际根底上，推出了「百幄」政企数智办公系列产品，助力政企数字化转型，实现政企办公的线上化、数字化和智能化落地。「百幄」以 IM 即时通讯和 RTC 实时音视频为外围 PaaS 能力，联合日常办公所需场景，通过开箱即用的利用套件能力和灵便不便的第三方平台整合能力，全面实现对立利用入口、对立通信服务、对立用户体系。 围绕政企办公畛域波及到的人、工作、常识、业务、场景等，「百幄」交融各类业务办公利用与企业沟通能力，将以更切实的产品价值，助力政企欠缺企业办公状态、晋升工作环节的数字化程度。 01 扩大日常沟通形式实现单聊、群聊、音视频会议、在线直播等场景，加强政企数智办公平台的连贯属性，不仅能够增强外部组织协同，还能通过即时通讯和视频会议增进产业链上下游搭档的分割。 02 进步日常办公效率通过技术交融、业务交融、数据交融，实现对立办公平台入口，同时将原有的被动工作告诉转换为被动告诉，防止人找音讯，而是通过智能化伎俩让音讯找人。 03 晋升协同管理水平通过与在线文档、待办和业务利用的整合，实现外部办公线上化、数字化和智能化，将原有的繁多业务零碎管理模式转变为跨零碎的协同办公能力，全面晋升外部工作效率。 ｜两大套件｜满足政企组织八个业务场景需要在服务模式上，「百幄」以平台化降级晋升集成能力和产品包容性，同时解耦要害性能，提供数智办公套件、会议直播套件等开箱即用的套件平台，让产品性能以客户需要为核心自在集成，并可填补企业大量增量需要和存量替换需要，满足政企客户八大业务场景需要。 01 数智办公套件以 IM 即时通讯为切入点，「百幄」的数智办公套件集成了待办治理、PIN 音讯、VoIP 通话、日程日历、组织治理、通讯录治理等残缺性能，打造一个对立办公平台，可满足政企组织内外沟通、党建学习、行政办公及业务流转等日常工作需要及其他个性化办公需要。 通过对立待办揭示、对立日程治理等能力降级，实现政企办公模式的变革，在信息无效触达和对立治理的同时升高组织沟通老本；反对多端同步无缝对接，满足政企组织随时随地高效协同的需要，推动跨地区、跨层级、跨部门的纵横联动和协同办公。 02 会议直播套件政企组织规模宏大、地区散布广、会议场景多样，需通过高品质的会议直播能力来晋升企业跨地区沟通合作效率。 「百幄」的会议直播套件，实用于政企组织的在线合作、近程办公、线上研究等场景；提供预约会议、退出会议、立刻散会等多种会议治理性能；反对共享白板、会议录制、会议记录、共享屏幕等多种能力，助力多人高效合作。 针对参加人数泛滥或受众地区散布极广的重要会议、产品发布会、大型年会、近程培训等场景，「百幄」的会议直播套件可无效补充视频会议在局部应用场景中的缺口，帮忙政企组织疾速实现超低延时直播能力，并通过直播连麦等特色性能，助力政企直播实现更多线下场景的线上化转型。 融云「百幄」套件利用场景

作者：贺迷信（晨末） 写在后面上一篇文章讲了如何构建业务大图，看到有评论说这和设定 OKR 差不多啊。心愿其余读者不要被相似的认识带偏。业务大图是业务顶层设计，是战略目标、业务长期价值、业务维度拆分、业务组织设计、业务长期倒退方向、要害业务战斗、短期重点事项的综合信息载体，是一个业务的宏观全貌，同时以业务战斗的模式跟进要害事项的执行过程。 而 OKR 是一套指标治理、推动执行与单干的工具和办法。其中 O 是指标，KR 是针对这个指标的能够掂量的要害后果，其侧重点在执行跟踪而不在业务顶层设计。当然如果肯定要用 OKR 进行业务顶层设计，那就会发现现有的 O、KR 都不能把顶层设计的要害因素讲清楚。所以说，在有了业务大图的根底上，OKR 是一个组织内不同层级、不同职能的团队或人，依据对业务大图的了解和业务策略的解读，在以后的执行周期（一个财年或天然年）内，对执行过程的管理工具和方法论。因而能够看出，业务大图和 OKR 的档次不同、要解决的问题不同、起到的作用不同、应用办法也不同。 能够说，前者是后者的前提和根底，前者蕴含了后者；后者是前者的保障和落地办法之一（OKR 不是惟一的业务策略落地办法），是前者的一部分。 最初用一个简略的图来示意业务大图和 OKR 的差异，如下： 图 1 业务大图与 OKR 别离作用于哪个业务倒退阶段 留神，图 1 是定性分析的示意图，非定量分析的准确图表。如图所示，从执行的视角来看，一个业务在最粗粒度上能够划分为两个阶段：业务顶层设计阶段、业务落地执行阶段。在图中咱们能够看到业务大图的建设横跨两个阶段，重点笼罩业务顶层设计，同时在执行阶段，也对要害事项以“业务战斗”的形式进行了笼罩。OKR 的设定和跟踪侧重点在执行阶段，当然也能够在业务顶层设计阶段就针对一部分事项做 OKR 拆解，所以两种方法论的作用范畴和业务倒退的两大阶段并不是严格对齐的，定性图表不再进行进一步解释了。 讲清楚两者的差别之后，解释一下为何要花费肯定的篇幅深入探讨这个问题。因为作者分享“如何画业务大图”的本意就是心愿读者在看到介绍构建业务大图的办法之后可能逾越层级壁垒，以决策者的视角，在宏观尺度“对新业务进行设计、对老业务进行回顾扫视”。 而评论区的“和 OKR 差不多嘛”一句话一下子就把没有认真分别二者差别的读者拉回到了执行者的视角，让这些读者真的认为 OKR 和业务大图是一回事，打断了这些读者站在更高层次去看业务的尝试，让这些读者误以为“我曾经会 OKR 了，所以不必管业务大图了”。而事实上，“业务大图”也只是模式，重要的其实是它在模式背地的内容，更重要的是读者依据剖析思考总结得出这个内容的过程。可是 OKR 所产出的内容和业务大图不一样，它的设定过程也并不能齐全代替构建业务大图的过程，这正是两者最外围的差别。 另外还有一点就是，作者自己作为技术人，在感性、捕风捉影、谨严认真方面对本人有比拟严格的要求，因为上一篇文章没讲 OKR，所以在有读者探讨“业务大图和 OKR 差不多”的时候，就感觉本人有必要讲清楚两者之间差不多到底是差多少？差在哪儿？哪儿不差？这些问题肯定要搞得清清楚楚明明白白，能力让本人看清问题实质，理解不同的“方法论”和“实践工具”的实用场景和范畴，能力利用好它们，彻底解决工作中遇到的问题，所以破费肯定的篇幅把相干的思考分享进去。 在聊完了二者的差别之后，其实有一点是二者都独特关注的，那就是对于业务指标的设定，也正是本文的主题：如何设定业务指标。也正是因为两个方法论都非常重视这部分内容，所以接下来咱们就这个主题开展具体的探讨。 你最相熟的“SMART准则"不是“设定指标”的银弹SMART准则（S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound），指标应该是具体的、可掂量的、可实现的、有相关性的、有时限的。 每次聊到设定业务指标，很多人都会不谋而合地提到 SMART 准则，也可能针对特定业务给出几个看起来合乎 SMART 准则的指标。可是深刻沟通下来，简直很少有人能讲清楚以下几个问题： 这件事件的指标为什么是这个？有没有其余更值得设定的指标？以后的指标的值为什么是这个值？这个指标达成了对业务有什么影响？达不成会对业务有什么影响？这个业务指标对其余合作方有影响么？影响是什么？打算如何实现这个指标？为什么定制了合乎 SMART 准则的指标，却答复不了这些最根底的问题呢？其实问题的本源在于 SMART 准则是你的指标曾经确定下来之后，用来帮忙你标准指标的表现形式，帮助你查看某一个指标的表述是否是“具体的、可掂量的、可实现的、有相关性的、有时限的”，从而让你把指标的全副要害因素清晰地表述进去，然而它并不能帮你把业务指标是什么定下来，也没方法指引你如何明确业务指标，如下图所示： 图 2 SMART 准则在业务指标定制过程中起作用的阶段 从上图咱们能够看到，如何剖析一个业务目前的状况，如何设定业务指标是两个须要答复分明的问题。市面上很多方法论喜爱讲如何做事，给出 1、2、3、4、5 这样的操作步骤，却从不谈这 12345 的步骤和程序是如何得出的，也不谈为什么不是 54321 或者不是 678910。也就说，很多方法论自身是否科学合理，在并没有被探讨到的状况下就被间接应用，讲师只知其一;不知其二，学员只能照猫画虎。我置信很多读者加入过一些培训，讲了如何设定指标，可是讲的其实都是“设定的指标怎么合乎 SMART 准则”，没有讲清楚到底怎么给业务设定指标，接下来本文就从源头开始一步一步讲清楚如何给业务设定指标。 ...

一、代码1.判等问题问题场景： 在理论业务开发过程中，比拟值，对象或类型判断是十分常见的，可是有时显著数值雷同的状况，却判断为不等，导致后续业务谬误（对账业务，枚举类型判断） 可能起因： ==和equal的谬误应用;判断对象是否是同一个，没有重写hashcode()和equal()办法;谬误将包装类型和根本类型比拟，或者更低级谬误就是不同类型进行比拟int和String起因剖析： equals 和 == 的区别 对根本类型，比方 int、long，进行判等，只能应用 ==，比拟的是间接值。因为根本类型的值就是其数值。对援用类型，比方 Integer、Long 和 String，进行判等，须要应用 equals 进行内容判等。因为援用类型的间接值是指针，应用 == 的话，比拟的是指针，也就是两个对象在内存中的地址，即比拟它们是不是同一个对象，而不是比拟对象的内容。在一些状况Integer和String也能够间接用==判断（java数值缓存[-128,127]和字符串驻留） Integer a = 127; //Integer.valueOf(127)Integer b = 127; //Integer.valueOf(127)log.info("\nInteger a = 127;\n" + "Integer b = 127;\n" + "a == b ? {}",a == b); // trueInteger c = 128; //Integer.valueOf(128)Integer d = 128; //Integer.valueOf(128)log.info("\nInteger c = 128;\n" + "Integer d = 128;\n" + "c == d ? {}", c == d); //falseInteger e = 127; //Integer.valueOf(127)Integer f = new Integer(127); //new instancelog.info("\nInteger e = 127;\n" + "Integer f = new Integer(127);\n" + "e == f ? {}", e == f); //falseInteger g = new Integer(127); //new instanceInteger h = new Integer(127); //new instancelog.info("\nInteger g = new Integer(127);\n" + "Integer h = new Integer(127);\n" + "g == h ? {}", g == h); //falseInteger i = 128; //unbox(java会主动拆箱)int j = 128;log.info("\nInteger i = 128;\n" + "int j = 128;\n" + "i == j ? {}", i == j); //trueString a = "1";String b = "1";log.info("\nString a = \"1\";\n" + "String b = \"1\";\n" + "a == b ? {}", a == b); //trueString c = new String("2");String d = new String("2");log.info("\nString c = new String(\"2\");\n" + "String d = new String(\"2\");" + "c == d ? {}", c == d); //false#应用 String 提供的 intern 办法也会走常量池机制String e = new String("3").intern();String f = new String("3").intern();log.info("\nString e = new String(\"3\").intern();\n" + "String f = new String(\"3\").intern();\n" + "e == f ? {}", e == f); //trueString g = new String("4");String h = new String("4");log.info("\nString g = new String(\"4\");\n" + "String h = new String(\"4\");\n" + "g == h ? {}", g.equals(h)); //true==留神：特地在开发中定义枚举类型时，判断状态或类型要留神= =和equeal的应用（特地是Integer和int）== ...

互联网的账号自带备忘机制；一、业务背景通常在零碎研发的过程中，须要一直适配各种业务场景，扩大服务的畛域和能力，个别会将构建的产品矩阵划分出多条业务线，以便更好的治理； 因为各个业务线的数据入口和管理策略的不同，这样从不同门路下积淀的数据，可能因为零碎边界问题从而被孤立；如果用户数据被决裂，会因为数据不全面给剖析决策带来误导； 比拟经典的场景，用户从利用端实现注册之后，通常不会过多提供本身信息，因为业务须要不断丰富用户画像，所以用户数据通常会被调度到独立的管理系统中，通过不同的触点反馈进行信息扩大，比方采集埋点数据，线下接触，营销电话等； 这种状况从操作上是有显著感知的场景，显然用户在利用库中的数据和在治理库是存在很大差别的，在实在的状况中用户可能在不同的利用和场景中会产生反复，必然会导致用户数据难以对立保护； 二、惟一标识用户的行为数据在当下的互联网产品中，是极其具备剖析价值的，不同的利用端不论是否处于登录状态，在产品中产生的数据都是有记录的伎俩，进而在数据层面剖析辨认； 这些编号最大的特点就是具备唯一性，能够标识用户在不同终端不同状态的操作信息，而当这些数据积淀到零碎时，会依据端口和操作类型进行存储，不同的终端下其数据惟一标识也不雷同； 从数据分析的角度上来看，显然不心愿用户的行为信息被决裂并且各自孤立，这样对多终端多状态下的用户行为数据进行全域关联，是卓有成效的形式，其基本原理波及到ID的映射技术； 三、Id映射基于上述的业务状况，在产品矩阵中提供用户身份的全局对立标识至关重要，用户实体在不同业务线所产生的行为数据，通过惟一序列号进行辨认，这样进行用户剖析时看到的画像比拟全面； 在当下的互联网产品中，基于手机号创立利用账号的模式曾经是常见性能，手机号注册之后，再通过手机号去关联相应的终端ID，从而使各种孤立的数据被链接起来； 其实现的原理并不简单，首先须要提供一套映射库，当新的手机号被零碎辨认采集时，在映射库中新建一条数据，手机号和对应的惟一ID，尔后其余门路的数据，如果手机号雷同则绑定在该ID上面； 四、数据关联在ID映射机制下，尽管各个业务线数据绝对孤立，数据之间不会产生间接影响，然而实际上曾经被惟一ID串联起来，这样将ID关联的数据进行综合剖析，准确性会进步很多； 不论从任何门路或渠道下采集的数据，如果存在手机号的维度，或者手机号相关联的序列号标识，判断该手机号是否存在全局映射ID，没有则在映射库中创立对应关系，如果有则间接绑定即可； 在执行数据的全局调度和剖析时，则通过映射库的规范关系，基于ID标识将全副业务线的数据进行查问和兼顾剖析，从而生成绝对全面的数据档案，以及规范的剖析逻辑；上面给出一个参考性的结构设计： 这里存在数据关联的逻辑，ID标识与手机号都是惟一的且一对一，然而手机号与终端的序列号可能存在一对多，甚至是多对多；账号与利用中产生的行为数据，尽管谋求准确性，然而精确度不会适度要求； 这种状况下就须要执行相应的业务策略，比方同一个手机号可能登录过不同手机中的雷同利用，手机中的利用也可能被多个账号登录过，此时则须要基于策略做关联上的取舍，可能是账号登录时长，或者登录前后的时段，无奈一概而论； 五、注册登录以手机号作为账号主体为例，凋谢的利用并不会显著区别注册和登录，以此简化操作防止阻断掉用户，在通过手机号登录时，如果是未注册的用户间接进行信息初始化即可； 用户在登录表单中，输出手机号并获取验证码；在登录服务中，生成并保护验证码的时效；验证码须要借助对接的第三方短信平台推送到用户手机中；登录表单填充验证码之后提交登录信息进行验证；当登录验证胜利之后，如果用户未注册则初始化账号体系；账号体系校验和保护之后，通过异步形式关联ID标识；最初须要给用户端返回Token身份令牌，作为账号辨认；注册登录集成在一起的复用接口比较复杂，然而以最短的门路让用户疾速应用产品，通过行为数据采集剖析，从而能够精准辨认用户需要，进行正确的疏导和营销，施展出数据的真正价值； 这里给出一份账号治理的结构设计参考，通常状况下用户的主表维度会围绕可登录的账号来设计，而波及到信息采集的数据会写入用户档案表，因为不同业务场景对信息依赖不同，所以在用户注册之后会疏导各种数据采集的页面； 用户身份辨认和账号作为零碎十分根底的外围能力，在设计的时候既要有用户体验，同时要器重数据的安全性；作为外围能力在后期设计的时候就须要肯定的前瞻性，做好可能性的布局和构造预留，防止后续的迭代跨度过大。 六、参考源码编程文档：https://gitee.com/cicadasmile/butte-java-note利用仓库：https://gitee.com/cicadasmile/butte-flyer-parent

前言随同公司业务疾速倒退，咱们生产环境产品和利用越来越简单，彼此连贯依赖也越来越简单；何一个利用出异样都有可能影响零碎可用性，造成全局影响。通过去年 2021 年 C 端故障全年度来看，从故障发现，响应工夫、故障应急有待晋升，故 NOC 要优化现有的告警响应品质，制订新的 NOC——SLA 体系化，规范服务等级协定！减速响应，做到事先发现！ 一、得物交易 C 端介绍1、C 端概念1.1 什么是 C 端C 端指的是消费者、个人用户 Consumer；顾名思义就是面向个人用户提供服务的产品，是间接服务于用户的，得物 C 端分为两个场景“交易”“社区”两个组成，C 端蕴含线上交易、社区、算法，波及到交易下的订单、出价 &库存、营销、商品，社区域前后端、算法交易举荐 &社区举荐为重要依赖。 1）交易角度用户登陆旅行商品详情在到领取购买，整个面向用户的交易流程就是交易 C 端业务。2）社区角度用户登陆登发帖，在到社区游览点赞、互动所产生的社交就是社区 C 端业务。 2、C 端呈现问题会怎么样？2.1 在 2021 年 6 中旬，商品服务异样因为技术问题导致订单间断上涨，影响用户下单购买体验。 举荐页面白屏无数据 &包含页面分类；商品侧：点击商品长时间加载或该商品下架不反对销售；出价 &存放侧：商品无奈出价、出价报错；供应链侧：影响局部分拣拍照甄别，以及查看商品详情页；社区侧：局部社区帖子加载过慢或延时；商家侧：开放平台 dop 也受到了大面积影响； 2.2 在 2021 年第四季度供应链发版中因为技术问题，代码 bug 和 redis 缓存解析异样导致交易订单当天上涨异样，影响了用户下单购买体验 出价 &库存：立刻购买浮层关上异样；创立订单 &领取订单：无奈关上创立；营销：调取优惠核销失败； 总结：随同公司业务疾速倒退，当初咱们生产环境产品和利用越来越简单，彼此连贯依赖越来越简单；一个利用出异样都有可能牵一发而动全身，影响全局。 二、针对 C 端历史问题-为什么要做 SLA1、告警问题发现1）在过来 2021 年度全年故障剖析中影响 C 端故障占比全年 34.7%，C 段告警发现率只有 42%。 在 C 端外围链路上的告警基本上曾经全副笼罩，然而在延长到所有故障类型重大故障上，咱们的告警覆盖面依然须要晋升。（监控告警零散，NOC 体系监控告警收口能力弱）在告警品质上没有无效收口。2）从 2021 年度至今故障剖析中 C 端中 NOC 的响应率从 3min-5min-15min 响应，来说所有待增强； ...

飞轮效应是一个不简单但高回报的实践，好的飞轮能够带来指数增长。很多人用飞轮效应解读万事开头难与保持。而我认为，飞轮效应的价值在于零碎思考。它用隐喻的形式将长期效应、零碎思考、洞察力这些让管理者事倍功半的工具和重要工作可视化的出现在了你的背后。你有没有发现： 有些公司能够构建继续倒退的能源，一直逾越新技术和行业的竞争继续做到从优良到卓越？而其它公司不行？有些团队可能长盛不衰，面对不同的挑战都能继续冲破？而其它团队不行？有些人可能经得住工夫和不同岗位的考验，继续打怪降级，实现跃迁？而其他人不行？对，我也发现了。那这外面有什么神秘吗？ 吉姆.柯林斯在《从优良到卓越》第八章提出的“飞轮效应”答复了这个问题。时隔9年后又将其独自写成新书《飞轮效应》（中文版往年4月刚刚上市），进一步阐释它的价值以及如何落地。飞轮效应不仅对一家企业的基业长青有很大的价值，对作为常识工作者的你以及你的团队同样具备指导意义。在碎片化的明天，不管是谁咱们都须要找准增长飞轮，专一继续能力从优良到卓越。 这篇文章给你分享一下我对飞轮效应的了解，蕴含如下内容： 什么是飞轮效应亚马逊的增长飞轮让飞轮施展效应的逻辑如何构建飞轮作为常识工作者的你写在最初一、什么是飞轮效应 基于多年的研究成果，吉姆.柯林斯认为：无论最初的后果如许富裕戏剧性，成就一家卓越企业绝不会欲速不达，没有惊人的翻新，没有侥幸的渐变，也没有奇观的霎时。相同，这个过程就像在继续地推动一个宏大又惨重的飞轮。一圈又一圈，你使劲地推动飞轮后退，通过继续一直的致力，你的飞轮转的越来越快，积攒势能，直到某个临界点实现冲破，飞轮的重力和冲力会成为推动力的一部分。这时，你无须再破费更大的力量，飞轮依旧会疾速的转动，且不停地转动，势不可挡。这就是“飞轮效应”。 你晓得吗? 那些能够继续从优良到卓越的公司的秘诀，正是因为厘清了本人的飞轮构造，确定第一推动力，并遵循让飞轮继续转动的法则，积攒蓄能，从而实现逾越与冲破。 二、亚马逊的增长飞轮在明天谈及飞轮效应必提亚马逊，谈及亚马逊也肯定会提飞轮效应。那，亚马逊的飞轮是怎么来的？杰夫.贝佐斯以及他的治理团队在2001年秋天与柯林斯学习了飞轮效应后，即着手构建了亚马逊的飞轮，运行至今。贝佐斯也将这称为公司胜利的‘秘密武器’[2]。亚马逊的胜利使更多的人理解到了飞轮效应的力量。上面让咱们通过亚马逊的飞轮来进一步了解飞轮效应是如何工作的。 下图是亚马逊的飞轮（据说是贝佐斯在一张餐巾纸上的手绘） （图1 亚马逊增长飞轮） 亚马逊的飞轮包含5个变量： 客户体验流量供应商低成本构造更低的价格它的逻辑是：好的客户体验带来更多的流量，更多的流量吸引更多的第三方卖家，第三方卖家提供丰盛的产品，带来更好的客户体验。与此同时，越来越大的规模使得亚马逊的经营老本被越多的在供货商这边摊派，从而取得低成本构造；低成本构造则会产生更多的收益，而更多的收益则会引起进一步的升高价格，更低的价格则带来更好的客户体验，从而周而复始。 从2001年到至今，包含将AWS变成对外服务，亚马逊都在一直的实际和迭代这个飞轮。而对于贝佐斯来讲，做批发和提供AWS服务这两件事件是一样的：更好的客户体验、更多的流量、更多的工具厂商入驻、规模化效应摊薄老本、更低的价格，周而复始。亚马逊的飞轮架构貌似有几个版本的变动，但其本质简直从未扭转。 吉姆.柯林斯在《飞轮效应》书中对其做了高度的概括。 （图2 亚马逊增长飞轮） 从上图咱们能够看出，晚期的亚马逊建设了高价、流量、规模化经营的良性业务循环模式，确保了正确的飞轮。贝佐斯又在一开始给飞轮注入了弱小的能源：为客户发明更多的价值。然，让亚马逊承受住工夫考验的要害并不仅在于此，而在于贝佐斯及其治理团队继续的推动飞轮，在不同局部加大投入减少飞轮的运行速度。通过周而复始的积攒与蓄能，造成继续运行的增长能源。 三、让飞轮施展效应的逻辑那飞轮背地的逻辑是什么呢？ 首先，飞轮运作的实质是零碎动力学的加强回路，前后节点互相加强。 在图2中，各个节点首尾相连，节点间具备很强的前后因果关系，因加强果，果反过来又会加强因，这就是加强回路，也即正反馈回路。 这样的例子事实中有很多，比方跑步越多精力越多，精力越多工作能够高效有更多的工夫跑步。学习的反馈也是一样。当然也有负反馈的例子，如迁延焦虑更迁延。 当加强回路作为良性循环的时候，它能够成为任何对象的成长发动机，也叫做成长引擎。而要让这样的引擎施展效应，须要把握激发它前后节点相互加强、放弃继续运行能源的逻辑程序。 其次，飞轮的构造是业务实质的体现，作为管理者的你须要放弃敏锐的策略洞察力。 从亚马逊的例子引申，咱们也能够用亚马逊的飞轮来了解京东、阿里和拼多多的业务。会发现只管他们的飞轮会略有不同，但实质都是围绕消费者从多、快、好、省的构造去定义本人的飞轮构造和终点。如果说京东抉择快为切入点，阿里则是多，拼多多则是省，从而取得更多的流量，吸引更多的商家，产生规模效益，降低成本构造，进而能够送的更快、能够更全、价格能够更省，客户的体验则会更好，实现正向的循环增长。 （图3 https://istore.alibaba.com/ca... 数字化时代以及后疫情，批发企业都将本人的业务做了新的延展。但，不论是什么样的智能批发，其本质是为了减少客户体验，批发业务的实质并没有发生变化的。这些新触点给宏大的企业飞轮注入了新的能源，从而继续的转动。 所以，看得出飞轮展现的构造绝不是某一具体的业务状态、某一具体的产品状态或翻新了多少，而是企业之所以存活的底层逻辑。 再次，飞轮须要继续注入能源并迭代。 飞轮是如何放弃能源的？飞轮难道始终不变吗？不可否认，随着工夫的变动，飞轮的回路会发生变化，包含子飞轮可能会产生全副的调整。那么你的企业须要依据状况对其进行调整，包含调整组件、组件之间的程序，亚马逊AWS服务的呈现就是一个很好的例子。 但你要留神，飞轮的调整并不一定是要产生大的改革。在一家公司倒退的历史上，飞轮进行运作的起因，并不是飞轮自身丢失了后劲或彻底生效，其起因有两个： 执行不当；没有依据工夫在良好的飞轮架构根底上进行迭代和延展。 （图4 来自网络） 这时候，你作为企业的管理者就要非常的警觉，因为当加强回路作为恶性循环的时候，就会引起业务的消退，造成厄运之轮。一个无效的办法就是对当下的问题进行诊断，找出关键点，以便进行将来的调整： 是没有保持飞轮的理念和方向？是晚期的逻辑已被淘汰，飞轮的组件须要更新？亦或是飞轮推动遇到阻碍，须要注入新的能源？总结，要施展飞轮效应须要如图的三个要害因素： 四、如何构建飞轮碎片化的时代，不论企业、团队还是集体都须要找准本人的增长飞轮。那么如何构建飞轮呢？这里有七步法帮你落地： 第一步，找胜利案例。列举出过来曾经实现的、重大的、可复制的胜利，包含远超预期的创举和新产品。第二步，找失败案例，列举出经验过的失败，包含那些远没有达到预期或彻底失败的动作和产品。第三步，将第一步和第二步的论断进行比照剖析，从中辨认飞轮的部件。比照胜利与失败的案例，并思考“从这些教训与教训中，咱们能发现哪些能够组成飞轮的部件”。第四步，画出飞轮。第五步，简化部件，不超过6个。第六步，用胜利案例和失败案例测验飞轮。第七步，应用刺猬实践的灵魂三问来测验飞轮。 这七步法其实是一个剖析、提炼和出现的构造，背地展示的是你对企业运作的洞察。因而，它更实用于有肯定运行工夫或规模的公司。如果你当初正遇到新的挑战的时候（例如疫情、数字转型），那么无妨邀请你的团队依照七步法从新进行盘点以再次起航。如果你是初创公司，也能够借鉴行业内的优良公司，依照他们获得成功的教训构建飞轮作为起步。 五、作为常识工作者的你常识工作者的逻辑是什么？ 常识工作者的外围逻辑是以常识为原材料，生产加工和变现，常识工作者的价值变现就在于别人是否能够高效高质量的生产你所产生的常识，不论在写计划、沟通、写代码等都是你的常识在被生产和兑现。 在这样一个常识焦虑和浅尝辄止的碎片化时代对常识工作者的考验就分外微小。各种常识满天飞，很多货色都要学都要精通，怎么办？ 首先，你能够借鉴上一节提到的构建办法对本人做一个人生大盘点，也能够借鉴行业中的翘楚，剖析他们的成功经验，构建或降级你的飞轮。 在这里，我分享一个最近和徐昊聊过的作为常识工作者的底层飞轮，其中让飞轮运行的能源则是工匠精力、价值兑现以及一直谋求卓越的酷爱与保持。 通过找准一个畛域深耕，让飞轮继续运行，继续变现，从优良到卓越最初则是顺其自然的事件。看到这里，你是不是依然有些焦虑呢？其实你也不必太放心，每一个人都有本人运行的飞轮，只不过你须要工夫找到它并继续推动。年初，我设计了一个100天的试验通过练习视觉笔记答复学习的实质到底是什么，明天是第82天，你瞧后果貌似也不错。 六、写在最初飞轮效应是一个不简单但高回报的实践，好的飞轮能够带来指数增长。很多人用飞轮效应解读万事开头难与保持。而我认为，飞轮效应的价值在于零碎思考。它用隐喻的形式将长期效应、零碎思考、洞察力这些让管理者事倍功半的工具和重要工作可视化的出现在了你的背后。 飞轮效应用在揭示咱们防止无目标的倒退及被动的响应，以陷入厄运之轮。当你所运作的规模越大业务越要害，以及所处的环境越加的不确定的时候，越须要警醒。一个卓越管理者的工作始终应该聚焦在企业的业务实质与加强回路；一直思考如何让飞轮施展最大效应，如何放弃连贯和蓄能，从而率领企业创下一个又一个的胜利。 碎片化的时代更须要专一于底层逻辑，更须要立足于长期且零碎的思考。不论是集体、团队还是企业找准你的增长飞轮，继续有积攒的连贯性成长，定能实现跃迁！ 起源：ThoughtWorks洞见作者：禚娴静 申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 5月每周四晚8点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址 0506 朱少民 《如何最大化软件测试效力》0513 陈琦 《数据驱动测试》0520 陈霁 《没错，去QA是提高质量最无效的办法！》0527 施慧斌 《DevOps实际之继续测试》

如何写好业务代码？ 在前端工作中有很多业务性代码，如果书写不规范，那么对后期的维护将是非常致命的。 判断配置化业务场景后端数据库中经常会一个字段具备几个不同的状态，比如： status: 2// 各个字段对应的含义0: 出生1: 儿童2: 少年3: 中年4: 老年这样不同的数字代表的含义，需要在前端展示。需要根据不同的状态，前端去做不同的处理方法一（switch）（bad）下面这段代码就是常见的无限if/else或者switch场景 // 业务代码switch (status) { case 0: // do something return '出生'; case 1: // do something return '儿童'; ... ... default: return '';}这样做是不好的，因为如果后端再加了一个字段，比如 5: 已死亡那么前端需要重新修改switch函数，这样需要去修改对应的业务函数，无疑破坏了业务代码的完整性。 方法二（写成配置文件）（better）// cfg.jsexport const cfg = new Map([ [0, 出生], [1, 儿童], [2, 少年], ... ... ]);// 业务代码cfg.get(status)但是这样仅仅是显示相关的状态，如果涉及到状态的判断，那这样的处理方式就有些问题了，比如需要根据具体的状态去做对应的判断 switch (status) { case 0: // do something return ; ... ...}像上面的情况，又变成了第一种情况，显然这种配置化的方式并不能满足。如果将对应的操作，与配置分割，则代码更加不易维护。 方法三（升级配置文件，处理代码集中）（better）将状态处理集中起来，如果能将状态展示和对应的状态封装起来，那么就会让后期代码维护显得十分集中。 ...

背景众所周知，日志是记录应用程序运行状态的一种重要工具，在业务服务中，日志更是十分重要。通常情况下，日志主要是记录关键执行点、程序执行错误时的现场信息等。系统出现故障时，运维人员一般先查看错误日志，定位故障原因。当业务流量小、逻辑复杂度低时，应用出现故障时错误日志一般较少，运维人员一般能够根据错误日志迅速定位到问题。但是，随着业务逻辑的迭代，系统接入的依赖服务不断增多，引入的组件不断增多，当系统出现故障时（如Bug被触发、依赖服务超时等等），错误日志的量级会急剧增加。极端情况下甚至出现“疯狂报错”的现象，这时候错误日志的内容会存在相互掩埋、相互影响的问题，运维人员面对报错一时难以理清逻辑，有时甚至顾此失彼，没能第一时间解决最核心的问题。错误日志是系统报警的一种，实际生产中，运维人员能够收到的报警信息多种多样。如果在报警流出现的时候，通过处理程序，将报警进行聚类，整理出一段时间内的报警摘要，那么运维人员就可以在摘要信息的帮助下，先对当前的故障有一个大致的轮廓，再结合技术知识与业务知识定位故障的根本原因。围绕上面描述的问题，以及对于报警聚类处理的分析假设，本文主要做了以下事情：选定聚类算法，简单描述了算法的基本原理，并给出了针对报警日志聚类的一种具体的实现方案。在分布式业务服务的系统下构造了三种不同实验场景，验证了算法的效果，并且对算法的不足进行分析阐述。目标对一段时间内的报警进行聚类处理，将具有相同根因的报警归纳为能够涵盖报警内容的泛化报警（Generalized Alarms），最终形成仅有几条泛化报警的报警摘要。如下图1所示意。我们希望这些泛化报警既要具有很强的概括性，同时尽可能地保留细节。这样运维人员在收到报警时，便能快速定位到故障的大致方向，从而提高故障排查的效率。设计如图2所示，异常报警根因分析的设计大致分为四个部分：收集报警信息、提取报警信息的关键特征、聚类处理、展示报警摘要。算法选择聚类算法采用论文“Clustering Intrusion Detection Alarms to Support Root Cause Analysis [KLAUS JULISCH, 2002]”中描述的根因分析算法。该算法基于一个假设：将报警日志集群经过泛化，得到的泛化报警能够表示报警集群的主要特征。以下面的例子来说明，有如下的几条报警日志：server_room_a-biz_tag-online02 Thrift get deal ProductType deal error.server_room_b-biz_tag-offline01 Pigeon query deal info error.server_room_a-biz_tag-offline01 Http query deal info error.server_room_a-biz_tag-online01 Thrift query deal info error.server_room_b-biz_tag-offline02 Thrift get deal ProductType deal error.我们可以将这几条报警抽象为：“全部服务器 网络调用 故障”，该泛化报警包含的范围较广；也可以抽象为：“server_room_a服务器 网络调用 产品信息获取失败”和“server_room_b服务器 RPC 获取产品类型信息失败”，此时包含的范围较小。当然也可以用其他层次的抽象来表达这个报警集群。我们可以观察到，抽象层次越高，细节越少，但是它能包含的范围就越大；反之，抽象层次越低，则可能无用信息越多，包含的范围就越小。这种抽象的层次关系可以用一些有向无环图（DAG）来表达，如图3所示：为了确定报警聚类泛化的程度，我们需要先了解一些定义：属性（Attribute）：构成报警日志的某一类信息，如机器、环境、时间等，文中用Ai表示。值域（Domain）：属性Ai的域（即取值范围），文中用Dom(Ai)表示。泛化层次结构（Generalization Hierarchy）：对于每个Ai都有一个对应的泛化层次结构，文中用Gi表示。不相似度（Dissimilarity）：定义为d(a1, a2)。它接受两个报警a1、a2作为输入，并返回一个数值量，表示这两个报警不相似的程度。与相似度相反，当d(a1, a2)较小时，表示报警a1和报警a2相似。为了计算不相似度，需要用户定义泛化层次结构。为了计算d(a1, a2)，我们先定义两个属性的不相似度。令x1、x2为某个属性Ai的两个不同的值，那么x1、x2的不相似度为：在泛化层次结构Gi中，通过一个公共点父节点p连接x1、x2的最短路径长度。即d(x1, x2) := min{d(x1, p) + d(x2, p) | p ∈ Gi, x1 ⊴ p, x2 ⊴ p}。例如在图3的泛化层次结构中，d(“Thrift”, “Pigeon”) = d(“RPC”, “Thrift”) + d(“RPC”, “Pigeon”) = 1 + 1 = 2。对于两个报警a1、a2，其计算方式为：例如：a1 = (“server_room_b-biz_tag-offline02”, “Thrift”), a2 = (“server_room_a-biz_tag-online01”, “Pigeon”), 则d(a1, a2) = d(“server_room_b-biz_tag-offline02”, “server_room_a-biz_tag-online01”) + d((“Thrift”, “Pigeon”) = d(“server_room_b-biz_tag-offline02”, “服务器”) + d(“server_room_a-biz_tag-online01”, “服务器”) + d(“RPC”, “Thrift”) + d(“RPC”, “Pigeon”) = 2 + 2 + 1 + 1 = 6。我们用C表示报警集合，g是C的一个泛化表示，即满足∀ a ∈ C, a ⊴ g。以报警集合{“dx-trip-package-api02 Thrift get deal list error.”, “dx-trip-package-api01 Thrift get deal list error."}为例，“dx服务器 thrift调用 获取产品信息失败”是一个泛化表示，“服务器 网络调用 获取产品信息失败”也是一个泛化表示。对于某个报警聚类来说，我们希望获得既能够涵盖它的集合又有最具象化的表达的泛化表示。为了解决这个问题，定义以下两个指标：H(C)值最小时对应的g，就是我们要找的最适合的泛化表示，我们称g为C的“覆盖”(Cover)。基于以上的概念，将报警日志聚类问题定义为：定义L为一个日志集合，min_size为一个预设的常量，Gi(i = 1, 2, 3……n) 为属性Ai的泛化层次结构，目标是找到一个L的子集C，满足 |C| >= min_size，且H(C)值最小。min_size是用来控制抽象程度的，极端情况下如果min_size与L集合的大小一样，那么我们只能使用终极抽象了，而如果min_size = 1，则每个报警日志是它自己的抽象。找到一个聚类之后，我们可以去除这些元素，然后在L剩下的集合里找其他的聚类。不幸的是，这是个NP完全问题，因此论文提出了一种启发式算法，该算法满足|C| >= min_size，使H(C)值尽量小。算法描述算法假设所有的泛化层次结构Gi都是树，这样每个报警集群都有一个唯一的、最顶层的泛化结果。将L定义为一个原始的报警日志集合，算法选择一个属性Ai，将L中所有报警的Ai值替换为Gi中Ai的父值，通过这一操作不断对报警进行泛化。持续步骤2的操作，直到找到一个覆盖报警数量大于min_size的泛化报警为止。输出步骤3中找到的报警。算法伪代码如下所示：输入：报警日志集合L，min_size，每个属性的泛化层次结构G1,……,Gn输出：所有符合条件的泛化报警T := L; // 将报警日志集合保存至表Tfor all alarms a in T do a[count] := 1; // “count"属性用于记录a当前覆盖的报警数量while ∀a ∈ T : a[count] < min_size do { 使用启发算法选择一个属性Ai; for all alarms a in T do a[Ai] := parent of a[Ai] in Gi; while identical alarms a, a’ exist do Set a[count] := a[count] + a’[count]; delete a’ from T;}其中第7行的启发算法为:首先计算Ai对应的Fifi(v) := SELECT sum(count) FROM T WHERE Ai = v // 统计在Ai属性上值为v的报警的数量Fi := max{fi(v) | v ∈ Dom(Ai)}选择Fi值最小的属性Ai这里的逻辑是：如果有一个报警a满足 a[count]>= min_size，那么对于所有属性Ai , 均能满足Fi >= fi(a[Ai]) >= min_size。反过来说，如果有一个属性Ai的Fi值小于min_size，那么a[count]就不可能大于min_size。所以选择Fi值最小的属性Ai进行泛化，有助于尽快达到聚类的条件。此外，关于min_size的选择，如果选择了一个过大的min_size，那么会迫使算法合并具有不同根源的报警。另一方面，如果过小，那么聚类可能会提前结束，具有相同根源的报警可能会出现在不同的聚类中。因此，设置一个初始值，可以记作ms0。定义一个较小的值 ℇ(0 < ℇ < 1)，当min_size取值为ms0、ms0 (1 - ℇ)、ms0 (1 + ℇ)时的聚类结果相同时，我们就说此时聚类是ℇ-鲁棒的。如果不相同，则使ms1 = ms0 * (1 - ℇ)，重复这个测试，直到找到一个鲁棒的最小值。需要注意的是，ℇ-鲁棒性与特定的报警日志相关。因此，给定的最小值，可能相对于一个报警日志来说是鲁棒的，而对于另一个报警日志来说是不鲁棒的。实现1. 提取报警特征根据线上问题排查的经验，运维人员通常关注的指标包括时间、机器（机房、环境）、异常来源、报警日志文本提示、故障所在位置（代码行数、接口、类）、Case相关的特殊ID（订单号、产品编号、用户ID等等）等。但是，我们的实际应用场景都是线上准实时场景，时间间隔比较短，因此我们不需要关注时间。同时，Case相关的特殊ID不符合我们希望获得一个抽象描述的要求，因此也无需关注此项指标。综上，我们选择的特征包括：机房、环境、异常来源、报警日志文本关键内容、故障所在位置（接口、类）共5个。2. 算法实现(1) 提取关键特征我们的数据来源是日志中心已经格式化过的报警日志信息，这些信息主要包含：报警日志产生的时间、服务标记、在代码中的位置、日志内容等。故障所在位置优先查找是否有异常堆栈，如存在则查找第一个本地代码的位置；如果不存在，则取日志打印位置。异常来源获得故障所在位置后，优先使用此信息确定异常报警的来源（需要预先定义词典支持）；如不能获取，则在日志内容中根据关键字匹配（需要预先定义词典支持）。报警日志文本关键内容优先查找是否有异常堆栈，如存在，则查找最后一个异常（通常为真正的故障原因）；如不能获取，则在日志中查找是否存在“code=……,message=……” 这样形式的错误提示；如不能获取，则取日志内容的第一行内容（以换行符为界），并去除其中可能存在的Case相关的提示信息提取“机房和环境”这两个指标比较简单，在此不做赘述。(2) 聚类算法算法的执行，我们以图4来表示。(3) min_size 选择考虑到日志数据中可能包含种类极多，且根据小规模数据实验表明，min_size = 1/5 报警日志数量时，算法已经有较好的表现，再高会增加过度聚合的风险，因此我们取min_size = 1/5 报警日志数量，ℇ参考论文中的实验，取0.05。(4) 聚类停止条件考虑到部分场景下，报警日志可能较少，因此min_size的值也较少，此时聚类已无太大意义，因此设定聚类停止条件为：聚类结果的报警摘要数量小于等于20或已经存在某个类别的count值达到min_size的阈值，即停止聚类。3. 泛化层次结构泛化层次结构，用于记录属性的泛化关系，是泛化时向上抽象的依据，需要预先定义。根据实验所用项目的实际使用环境，我们定义的泛化层次结构如下：“故障所在位置”此属性无需泛化层次结构，每次泛化时直接按照包路径向上层截断，直到系统包名。实验以下三个实验均使用C端API系统。1. 单依赖故障实验材料来自于线上某业务系统真实故障时所产生的大量报警日志。环境：线上故障原因：产品中心线上单机故障报警日志数量：939条部分原始报警日志如图9所示，初次观察时，很难理出头绪。经过聚类后的报警摘要如表1所示：IDServer RoomError SourceEnvironmentPosition （为保证数据安全，类路径已做处理）Summary （为保证数据安全，部分类路径已做处理）Count1所有机房产品中心Prodcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getProductType execution timeout after waiting for 150ms.2492所有机房业务插件Prodcom....PluginRegistry.lambdajava.lang.IllegalArgumentException: 未找到业务插件:所有产品类型2403所有机房产品中心Prodcom....TrProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: TrQueryClient.listTrByDids2C execution timeout after waiting for 1000ms.1454所有机房对外接口(猜喜/货架/目的地)Prodcom....RemoteDealServiceImplcom.netflix.hystrix.exception.HystrixTimeoutException: ScenicDealList.listDealsByScenic execution timeout after waiting for 300ms.895所有机房产品中心Prodcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.listTrByDids2C execution timeout after waiting for 1000ms.296所有机房产品中心Prodcom....ActivityQueryClientImplcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms.217所有机房产品中心prodcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms.218所有机房对外接口(猜喜/货架/目的地)Prodcom....RemoteDealServiceImplcom.netflix.hystrix.exception.HystrixTimeoutException: HotelDealList.hotelShelf execution timeout after waiting for 500ms.179所有机房产品中心Prodcom....TrProductQueryClientCaused by: java.lang.InterruptedException1610所有机房产品中心Prodcom....TrProductQueryClientCaused by: java.lang.InterruptedException13我们可以看到前三条报警摘要的Count远超其他报警摘要，并且它们指明了故障主要发生在产品中心的接口。2. 无相关的多依赖同时故障实验材料为利用故障注入工具，在Staging环境模拟运营置顶服务和A/B测试服务同时产生故障的场景。环境：Staging（使用线上录制流量和压测平台模拟线上正常流量环境）模拟故障原因：置顶与A/B测试接口大量超时报警日志数量：527条部分原始报警日志如图10所示：经过聚类后的报警摘要如表2所示：IDServer RoomError SourceEnvironmentPosition （为保证数据安全，类路径已做处理）Summary （为保证数据安全，部分类路径已做处理）Count1所有机房运营活动Stagingcom....ActivityQueryClientImpl[hystrix]置顶失败, circuit short is open2912所有机房A/B测试Stagingcom....AbExperimentClient[hystrix] tripExperiment error, circuit short is open1053所有机房缓存Stagingcom....CacheClientFacadecom.netflix.hystrix.exception.HystrixTimeoutException: c-cache-rpc.common_deal_base.rpc execution timeout after waiting for 1000ms.154所有机房产品信息Stagingcom....queryDealModelCaused by: com.meituan.service.mobile.mtthrift.netty.exception.RequestTimeoutException: request timeout145所有机房产品中心Stagingcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms.96所有机房产品中心Stagingcom....getOrderFormjava.lang.IllegalArgumentException: 产品无库存77所有机房弹性工程Stagingcom....PreSaleChatClientcom.netflix.hystrix.exception.HystrixTimeoutException: CustomerService.PreSaleChat execution timeout after waiting for 50ms.78所有机房缓存Stagingcom....SpringCacheManagerCaused by: java.net.SocketTimeoutException: Read timed out79所有机房产品信息Stagingcom....queryDetailUrlVOjava.lang.IllegalArgumentException: 未知的产品类型210所有机房产品信息Stagingcom....queryDetailUrlVOjava.lang.IllegalArgumentException: 无法获取链接地址1从上表可以看到，前两条报警摘要符合本次试验的预期，定位到了故障发生的原因。说明在多故障的情况下，算法也有较好的效果。3. 中间件与相关依赖同时故障实验材料为利用故障注入工具，在Staging环境模拟产品中心服务和缓存服务同时产生超时故障的场景。环境：Staging（使用线上录制流量和压测平台模拟线上正常流量环境）模拟故障原因：产品中心所有接口超时，所有缓存服务超时报警日志数量：2165部分原始报警日志如图11所示：经过聚类后的报警摘要如表3所示：IDServer RoomError SourceEnvironmentPosition （为保证数据安全，类路径已做处理）Summary （为保证数据安全，部分类路径已做处理）Count1所有机房SquirrelStagingcom....cacheTimeout4912所有机房CellarStagingcom....cacheTimeout2853所有机房SquirrelStagingcom....TdcServiceImplOther Exception1494所有机房评论Stagingcom....cacheTimeout1475所有机房CellarStagingcom....TdcServiceImplOther Exception1436所有机房SquirrelStagingcom....PoiManagerImpl熔断1127所有机房产品中心Stagingcom....CommonProductQueryClientOther Exception898所有机房评论Stagingcom....TrDealProcessorOther Exception839所有机房评论Stagingcom....poi.PoiInfoImplOther Exception8210所有机房产品中心Stagingcom....clientTimeout74从上表可以看到，缓存（Squirrel和Cellar双缓存）超时最多，产品中心的超时相对较少，这是因为我们系统针对产品中心的部分接口做了兜底处理，当超时发生时后先查缓存，如果缓存查不到会穿透调用一个离线信息缓存系统，因此产品中心超时总体较少。综合上述三个实验得出结果，算法对于报警日志的泛化是具有一定效果。在所进行实验的三个场景中，均能够定位到关键问题。但是依然存在一些不足，报警摘要中，有的经过泛化的信息过于笼统（比如Other Exception）。经过分析，我们发现主要的原因有：其一，对于错误信息中关键字段的提取，在一定程度上决定了向上泛化的准确度。其二，系统本身日志设计存在一定的局限性。同时，在利用这个泛化后的报警摘要进行分析时，需要使用者具备相应领域的知识。未来规划本文所关注的工作，主要在于验证聚类算法效果，还有一些方向可以继续完善和优化：日志内容的深度分析。本文仅对报警日志做了简单的关键字提取和人工标记，未涉及太多文本分析的内容。我们可以通过使用文本分类、文本特征向量相似度等，提高日志内容分析的准确度，提升泛化效果。多种聚类算法综合使用。本文仅探讨了处理系统错误日志时表现较好的聚类算法，针对系统中多种不同类型的报警，未来也可以配合其他聚类算法（如K-Means）共同对报警进行处理，优化聚合效果。自适应报警阈值。除了对报警聚类，我们还可以通过对监控指标的时序分析，动态管理报警阈值，提高告警的质量和及时性，减少误报和漏告数量。参考资料Julisch, Klaus. “Clustering intrusion detection alarms to support root cause analysis.” ACM transactions on information and system security (TISSEC) 6.4 (2003): 443-471.https://en.wikipedia.org/wiki…作者简介刘玚，美团点评后端工程师。2017 年加入美团点评，负责美团点评境内度假的业务开发。千钊，美团点评后端工程师。2017 年加入美团点评，负责美团点评境内度假的业务开发。 ...

前言：谈到“架构”这两个字，会有好多的名词闪现，比如:分层架构、事件驱动架构、DDD、CQRS等。亦或者一堆的软件设计原则，如：KISS原则（Keep it Simple and Stupid）、SOLID原则(单一责任原则、开放封闭原则、里氏替换原则、接口分离原则、依赖导致原则)等。甚至如状态图、用例图、时序图、活动图等UML建模，GOF设计模式等。本文不会讨论这些架构概念，而是从闲鱼详情页这个业务场景出发，分析出当前的业务问题和痛点，然后通过一步步的架构推导设计，解决这些痛点。随着业务的发展，相信这些问题大家都会遇到。而解决问题的过程，或多或少的会用到上面的设计原则。一：老的业务架构 - MVC架构很多同学开始写业务的时候，基本都会先建表，然后生成CURD，最后再堆业务逻辑，从DAO->Manager->Service->Controller一路写到底。在业务小的时候，这种架构非常的简单实用，可以快速的开发上线。但随着业务发展，人员不断增加，老的架构难以支撑业务的发展，稳定性和效率受到极大挑战。蛮荒时代已过，精耕细作的时代到来，急需一种更合适的架构来支撑业务的发展。以闲鱼的详情页举例，在业务初期，详情的样式只有普通的开价宝贝一种，但随着业务的发展，演变出拍卖、免费送、租房、玩家等细分领域的商品详情页（我们将细分领域的业务命名为“垂直业务”）。 此时，还不断的在老的业务逻辑里添加新的业务逻辑，导致所有的详情业务逻辑堆在一起。于是乎，会出现下面的场景：1）今天A详情业务线的同学，加了段逻辑，挂了，影响了所有业务线的同学；2）B详情业务线的同学想做单独的监控、缓存、降级等，做不到啊，大家的逻辑在一起，改造成本太高；3）C详情业务线的同学本想只关注C详情业务逻辑，发现所有业务都在一起，不得不将所有业务都理清楚一遍；4）D详情业务线的同学发现前面的业务逻辑太复杂，为了将影响面减少到最小，找了一个认为最安全的地方，加了一段D详情业务的特殊处理。有人可能会问，堆逻辑正常的啊，加几行代码，业务就上线了，互联网提倡的敏捷开发，当然是怎么快怎么来。但敏捷开发 != 提需求 + 编码 + 发布，加几行代码交付业务上线，可能会带来眼前的收益，但一直这么下去，代码会越来越臃肿，没有设计和文档沉淀的系统，难以维护，出故障只是时间问题。二：新的业务架构 - 业务隔离 + 领域建模吉德林法则讲：把难题清清楚楚地写出来，便已经解决了一半。 老的架构的问题，归纳起来讲：1.业务没有做隔离，所有的垂直业务逻辑都堆在一起，互相影响。2.详情页业务足够的复杂，却没有统一的模型，形成统一的认知。因此，架构的设计方案就着重解决这两个问题。2.1 业务隔离架构推导与设计一个业务，有多种形态的实现，很容易对应到设计模式里的策略模式。最粗暴的方式，每个垂直业务都自己实现详情页。这种方式，业务虽然隔离了，但维护成本极高，添加一个通用的功能，所有业务都需要添加一遍。 因此需要将共性内容（不变的部分）抽象出来，将变化的部分由各个垂直业务去实现。这种方式，解决了业务的隔离，共性的内容统一维护，变化的部分由各个垂直业务独立维护。但此时，所有的业务团队还是在一个应用工程里写业务代码，会出现如下场景：1)开发阶段，各业务线都在这个应用里拉取一个分支进行开发，集成部署时，代码冲突难以避免。2)A业务线添加了一段自己业务线的逻辑，部署失败了，导致其它业务线也无法使用。3)N业务线不在自己的团队内，属于外部合作团队，如何添加该业务线的逻辑。这些场景存在的原因在于，业务代码虽然隔离了， 但人员的开发过程并没有隔离。有如下3中方法可供选择:a. 将共性的内容打成二方依赖包，每个垂直业务依赖这个二方包，进行独立应用开发。这种二方依赖的方法最常用，但在二方服务里添加一个通用功能的时候，要告知所有业务方都升级二方包，还要发版，升级的成本高。b. 垂直业务独立应用开发，然后将代码打成jar包，再集成到共性业务应用里，一起部署。该方法依赖关系跟方法a相反，但部署方式不够灵活。如果要实现垂直业务的独立部署，改造成本太高，需要做类隔离，budle隔离等。综合a和b的优点，将共性的业务独立部署，垂直业务既可以独立部署，也可以写在共性内容应用里。当调用某个垂直业务实现时，可以自动路由到具体的垂直业务实现（这个垂直业务实现可以是一个本地调用，也可以是一个远程调用）。这样，垂直业务的开发人员就可以在自己的应用中开发、部署、运维，解决开发人员的隔离问题。至此，业务的隔离，开发人员的隔离问题都已解决。但该架构方案显然不只有详情这一个场景可用，其他类似的业务场景也有相似的问题。因此，架构的代码不能与业务的代码耦合在一起，需要将架构的代码独立出来，形成通用的技术工具，以应用于所有类似的业务，业务开发应该只关心业务的事情。我们特地为此开发了一个多实现“业务隔离”路由工具，最终的隔离架构设计图如下：2.2.领域模型在详情页的使用隔离的问题解决了，再来谈谈详情页的领域建模。为何需要领域建模？好多java开发的同学，大都会遇到这样的问题：1）一门OO(面向对象)的语言，写出来的代码都没有OO的感觉，到像是过程式的代码，面向对象的思想基本没有使用到。2）虽然代码满足了业务需求，但从代码中，完全看不到业务领域的影子，业务领域和代码是脱节的。3）随着业务的越来越复杂，里面的依赖关系梳理起来非常困难，业务模块没有边界可言。为了不给后人挖坑，为了解决详情页复杂的逻辑，为了让代码更有范，为了让接手详情的同学都有统一的业务领域认知，因此决定对详情领域进行领域建模。Eric Evans的那本《领域驱动设计——软件核心复杂性应对之道》经典书籍大行其道十几年，网上关于领域建模的文章也是浩如烟海，自顶向下、自底向上、四色原型建模、问题空间领域模型抽象方法论也非常的多。但这些文章和书籍，要么谈论理论概念，要么谈论建模方式，对初学者来说，看完之后，还是写不出相应的代码。所以本文不在重复的去讲领域建模的概念，直接通过闲鱼详情页这个业务场景，讲述建模的步骤、DDD的代码展示，给读者一个更直观的参考。2.2.1 详情页领域建模闲鱼详情页是一个纯展示的页面，用一句话可以概括为，“详情页是包括：商品、卖家、买家、鱼塘、认证、互动等内容的信息聚合展示页” 。这里我们使用四色原型建模法进行建模。上面的这句话最骨干的内容为：详情页是一个“信息聚合展示页”（瞬间事件）。骨干内容定义好后，为了更好的描述详情页是什么，需要补充一些实体对象，详情页主要包含商品、卖家、买家、鱼塘这些实体（人-物-地点）。在此基础上，进一步的进行抽象，用户实体中，有卖家、买家这个角色存在；鱼塘实体中，又有塘主、塘民角色存在（塘主也是塘民，所以塘主应该继承自塘民）。加入角色后的模型如图11所示：最后，再把一些描述信息放进去有了模型的设计，再转为类图设计。根据模型的抽象，详情页是信息展示的聚合，因此它是个聚合根，包含了商品、卖家、买家、鱼塘这些实体信息。 商品信息描述里，又有视频、图片、文本、互动等信息。视频、图片可以抽象为媒体信息。使用UML设计出最终的类图，如图13所示2.2.2 DDD代码展示在实现详情页时，依据的是DDD中的定义。DDD中最主要的内容包括：entity、value object、aggregate、repository、factory和service （如图8所示）， 以及Infrastructure, Domain, application和User Interface 分层结构，如图14所示：Infrastructure主要用于持久化数据的读取和写入；Domain为领域层，提供领域信息，这是业务的核心所在；Application是很薄的一层，没有业务逻辑，用来协调应用活动；User Interface负责用户信息展示。将这个分层结构映射到工程结构如图15所示。这里的Applicaiton层没有业务逻辑，只作为二方服务对外提供。此外，工程结构中没有写User Interface层，因为该应用是以二方服务提供，当然，如果提供REST服务，则可以写在这一层。多数的用户对MVC架构比较了解，因此，图16对比了DDD的分层架构和MVC的架构，以做参考。根据上文的模型抽象，领域对象主要有 ItemEntity, SellerEnity, BuyerEntity, FishPoolEntity，并通过详情页聚合根DetailAggregate聚合。在图15应用结构分层中，有3种类型的数据对象，DO对象表示持久化的数据对象， Entity为领域对象，DTO为对外的传输对象。首先通过领域层的Repository，调用基础设置层的Dao读取DO结构，再使用Convertor转为Entity领域对象。领域entity处理各自的领域业务逻辑，然后通过领域层的DetailService，对聚合根DetailAggregate进行整体详情页业务领域处理。最后转为DTO传输对象提供对外服务。三: 总结和思考本文从详情页业务出发，当业务越来越复杂时，如何做业务的隔离，做开发人员的隔离，以及如何通过领域建模，形成统一认知。给大家提供一个可行的参考。但没有任何一种架构可以适用于所有的场景，也没有任何一个架构是最优的，所谓架构，都在解决“边界”的问题。因此都需要从实际的业务场景出发，明确出问题的边界在哪里，要达到什么样的目标，再遵循一些基本的原则和方法，基本都能够设计出符合自己业务特性的架构。接下来将会给大家分享一篇从不同的视角出发，进行的业务架构设计。本文作者：闲鱼技术-绛曲阅读原文本文为云栖社区原创内容，未经允许不得转载。

个人博客地址：猫叔的博客 | MySelf前言之所以写这篇文章其实辩论性很强，这里不是针对所有地区、所有的互联网类型科技型公司，仅仅是我目前所处在大环境与场合是这样的。公司地处东南方，算是大型国企的全资公司，不是私企性质，虽然不是私企但是其实存活的状态也是自己养活自己，可能跟多的是存在一个大的靠山罢了。由于最近附近与自身所处的环境都在改革，与大规模裁员，在与几个管理层讨论后有所感悟，可能只是个人的狭小视野，所以还望各位见谅鄙人的拙见。很多公司都在“砍人”，我们也是前段时间，周边的各个同行业的朋友都在抱怨行情不好，当时其实还没有太大的在意，因为身边暂时还是稳定的，但是互联网产业更多都是互通的，这些其实都是迟早的事，我们几个同级公司也出现了政策改革，为什么？养不起了！一个开发团队的成本是巨大的，市场在开拓，不停的接到新的项目，合同一签就把项目丢到研发团队，即使研发这边不停的加班，其实各个项目的成果与进展也不尽人意，甚至是研发的负责人还不时向老板提出：“人手不够，加班也做不完，需要招人”。可是我们签的单子的纯利润才多少？现在招一个开发又要讲究什么五险二金，各种福利才能招到好的人才，成本实在是太大了，这里的公司偏向于项目型的，包括部分具备主导产品的。是的，我们如果做技术公司又要有技术基础，技术积累，可是辛苦培养的人才也可能随时流失，这样真的有意义吗？我司也开始了“砍人”的节奏，你整天可以敲代码，可是你的代码对于市场来说究竟能卖多少钱，可能这个收入还不及付给你工资，加上AI、高新互联网技术产品的推出，部分业务与功能完全可以花一点钱，由大厂的产品来运作，甚至更高效，那么我何乐而不为呢？你要转型，要么牛逼如果你只是完成每天上级交给你的任务，并完成的很疲惫，实现了的功能还可能被砍掉，甲方爸爸随时说不行的话，那么你的工作有点危险，不管是产品经理还是老板都更多希望你能完成的符合业务，符合用户的要求与想法，而不是你想想中的我这个类用了单例模式、我这里的性能优化快了5秒，是的，产品经理的市场开始上升，因为实现一个产品现在不难，但是做出一款符合市场，并且使具备刚需的产品是一个难题，用户希望看到的是这笔钱花的值，什么是值？回利周期短，见效快，流量高，那么你一个敲代码的人，实现一个页面数据的人，可是把控吗？（这里可能有点严重了，抱歉，个人拙见）老板希望你不仅能做售前，还能敲代码，那么你的利用价值更高，而且很吃香，你会和用户交流需求，你会和市场部的人探索为什么这样做，而且选择成本最低的技术方案，这是你一个技术人员对于一个迫切需要存活的公司的最大帮助，可能这里有些违背了什么我们是程序员的初衷（代码至上），当时如果公司都没办法养你，那么请问你去哪里敲代码？要么你的技术非常牛逼也是可以的，在面对各种产品需求的时候，可以一目了然的说出各种技术的实现方案与成本报价，同时知道难点与业务痛点的实现核心，在不砍掉核心业务的情况下，实现这个产品，那么公司一定还会继续留着你，因为你具备带技术人员的能力，你可以减少开发人员一头转进死胡同，帮他们必过一些不必要的技术摸索。不牛逼的给我懂市场和业务其实没必要一定要开掉这些开发人员，毕竟国企的环境可能还不一样，因为特殊的因素，当时也不是说可以一直养着一些看不下去的人，每个人都具备转型的机会，如果…写到这里我自己也有点难写下去，因为其实还不是到这个程度，但是部分环境是这样的，你实现了一个月的代码，可能可以通过更便宜的成本得到，如果是那么没有雄厚研发资金的团队来说，他们烧不起这些钱，他们更愿意选择外协或者合作的形式来实现快速的资金回利。我总觉得我还太快下结论了，这个互联网市场确实来到了寒潮，可是真正的原因是市场，以前开发没有那么大热的时候，开发人员是很吃香的，因为很多老板想要的功能更多是去自己招人开发，然后巩固自己的技术壁垒，可是现在已经不是那个时候了，游戏大寒潮，广州几百游戏公司，一个月剩下不到一半，各大厂停止招聘（其实还有招人），很多公司裁员，因为现在是要铺市场，你说要做一个什么东西或者产品，可以用最低的成本获取到，各种途径，可是你的市场能不能做起来就是另一回事了。短视频崛起、微信、新浪升级、知识付费、OFO事件、是代码影响的结果吗？我也近日在思考做程序员除了实现还有什么？做内容大V，内容创业？不需要搬砖的人，代码在老板眼里不值钱我需要一个能在技术上统筹全局的人，而不是一头盯着屏幕天天敲代码的工人，老板很现实，其实这个社会一直如此。你给我看你今年给我这个公司创造了多少营收，你的代码实现、实施能够值多少钱？可是你会说，这是市场的问题呀！他们开拓的市场，需求没有找对，我只是实现固定的要求而已，那么老板可以在你实现完成后，留下一两个统筹项目的技术人员，然后其余的都砍掉，因为这个产品的市场完全养不起我当时招的这个研发团队。就像最近我和另一个团队的Leader，他和我一起和他团队开会，向团队询问道：“现在要在产品加一个IM系统，具备市面上的基本功能？”其中一个年轻的小伙子说，可以用某某技术+某某技术+什么类型的数据库来实现，而且还清晰的说出了可能面对的难点，他的实现思路还是正常且符合逻辑的，可是旁边另一个老伙计在笔记本上敲了几下，说到现在开源且比较稳定的IM项目有某某、某某或者使用一些成熟的商家的IM产品接入项目也可以，成本与周期会很快，那么请问你是老板你选哪个？如果给你20万启动资金，去做一个互联网项目，一年内回本吧，你要怎么搭配开发人员？（这里笼统的比喻一下）.jpg)你还有可塑性吗？存在固化思维吗？如果你是技术Leader，你希望带什么样的人？假如现在你的团队有15个开发人员，老板突然说最近市场不好，要你砍掉一半，那么你会留下什么样的人才跟着你？老板还说，如果接下来的一年，你带的这个团队没有创收，那么这个团队一锅端，你会怎么想？我想我会留下一两个很听话，同时一定留下具备可塑性的人才，他们的适应力强，可以随着项目的一些硬性需求做出一些转变。其实你自己一个人在那里每天完成固定的功能，实现的过程中可能遇到一些BUG或者难题，每天都有些累，你可能也会抱怨不平，可是你要再想想如果你来做Leader，你来管理，特别是技术管理，那么我想你会天天失眠的，因为你除了要完成自己的本分工作之外，还要不定期开会、写报告、带着自己的团队去成长、养活自己的团队。职场很冷血、很现实，你可以自己在自己的位置每天无忧无虑的敲代码其实很美好。写到这里，我已经开始小迷茫了，当初每个夜晚的“勿忘初心”又是什么告诫？我热爱代码，我热爱开源。我享受成就感！如果你是这一行的，我希望你能问心无愧的说出这些话。接下来要怎么走？这是一个每个人自己的命题，我回答不上来！我也写不下去了，原谅我的拙见可能给你带来困扰，同时这个时代究竟发生了什么，我希望你能用自己的眼睛去看清楚，希望每一位读者都能找到自己的 “初心” 并 “勿忘”。我是MySelf，一个普普通通的程序员，我不是什么大牛、也不是什么业务专家，我也将是时代抛弃的一员，但是我仍在苟且，希望大家能抵挡洪流，走向下一片蔚蓝广阔的天空。

本文章通过玩事创新应用的发展之路，来介绍如何随着业务的不断发展抽象出的业务中台。玩事，不一样的做事方式。这是一个17年3月初开始创新孵化17年4月1日上线的创新产品。经过1年多的发展，从最简单的发荣耀功能，发展至今包含荣耀、荣誉、祝福、权益中心、金豆雨、学一下、猜一下、权益雨等多种创新互动的场景，并形成以基础数据、金豆、标签、权益为核心的中台微服务。下面谈谈玩事是如何基于iuap的PaaS平台快速构建业务，逐步抽象出核心的中台微服务。互联网界一直都在呼喊“大中台，小前台”的理念，但到底什么是中台呢？下面是iuap对中台的一个理解：中台更多是一种理念，大家以中台的方式思考和行动，业务发展是核心目标，中台能力沉淀是持续保障！中台不是简单的产品或者平台，她代表着全新的：业务服务模式+架构模式+组织协作模式图1 - 玩事中台架构图图2 - 玩事技术架构图玩事创建新应用是基于iuap的 gPaaS、bPaas、dPaaS平台快速创建的。gPaaS平台提供了开发运维一体化及基础的技术支撑，bPaaS提供了用户、员工、项目、企业账号、团队、消息等基础服务的支撑，dPaaS提供了数据收集、数据报表的基础支撑。在这些强大的PaaS平台技术的支持下，才有玩事的专注于业务创新。上线之初，玩事就初步具备了金豆、荣耀和权益三个应用，只是初期的功能非常简单。随着业务的不断发展，增加了很多的新业务：荣誉、祝福、拍砖、学一下、猜一下、投一下、权益券等。如果不对应用进一步的抽象出中台业务的话，业务中可能会存在大量的重复逻辑，非常不利于维护和未来的持续发展。以标签核心微服务的抽取过程来阐述下如何抽象业务中台微服务。下面是最初的发荣耀业务流程图：![clipboard.png](/img/bVbmXjp图3 - 荣耀发放流程图随着业务的不断发展，新增了发拍砖、发祝福、发荣誉以及扣减库存发荣耀等需求，他们的大致业务流程相同，却存在一些细微的差别。如果进行抽象，那么荣耀、拍砖、祝福、荣誉存在将会存在大量的重复业务逻辑和代码，浪费开发资源也不利于长远的发展。图4 - 荣耀、拍砖、祝福、荣誉发放流程图仔细观察我们会发现，荣耀、拍砖、祝福、荣誉存在一些共同的特性，他们实际上本身都是一个标签信息，区别在于荣耀、祝福、荣誉是转账金豆，拍砖是扣减金豆，荣耀支持用库存发放，祝福支持发权益券。为此我们抽象出一个标签的中台微服务。图5 - 标签抽象图当然标签微服务的能力和扩展点除了标签的业务操作外，还有校验、报错、IM消息等都可能存在细微的差别，都可以通过扩展的这种方式来完成对主题业务的抽象统一，细微差别的个性化操作。这样的好处在于，如果后续发荣耀的业务也要支持送权益券仅需要改个配置参数就可以了，不需要重复开发。抽象出业务中台服务后，可以将这些服务重新反补到bPaaS平台，提供给更多的应用使用这些能力，并逐步发展和壮大这些核心微服务。在实际的中台核心微服务抽取过程远比这复杂，但是要抓住业务核心，针对DDD领域建模，抽象出领域服务的核心能力，差别的操作通过扩展的方式来实现。只要抓住这些核心方法，相信一定可以抽象出合理的中台服务。

首先，我们解决一个问题，我们有了第一个方法。然后，我们想解决包含这个问题的一类问题，我们总结一个元方法。然后，我们想知道怎么样找到一类问题的方法的方法，这是就是元方法的元方法。或者说，元元方法。这样的一个不断上溯的过程，我称之为求元方法递归。从互联网业务-编程实际场景举例子，飞猪，大家都知道，阿里的在线旅行电商销售网站。飞猪最开始只是照搬了淘宝的下单组件，这个下单组件针对于一般商品的下单流程，他只能让用户填写收货地址和数量和品类。对于飞猪的签证业务来说，这样的下单组件起不了帮助。因为签证业务需要收集用户的关键护照信息，那么就只能靠客服一对一的聊天和用户确认信息。运营收集到行业商家的痛点，反馈给产品经理，产品经理思考这个需求点的合理性和整体流程，给到技术开发排期上线。好，至此为止，第一层 meta 元方法产生了。因为在这个新版的为签证业务定制的下单组件，用一个方法解决了一类问题的麻烦。那么我们该如何衡量这个元方法的业务/技术收益？元方法的收益应该是=(单个收益*适用范围-推广成本）。继续思考，元元方法的产生。我们来讨论第二层是怎么产生的。第二层，如果有很多个类似签证的业务方，比如邮轮，机票，酒店，电话卡，都要定制他们自己的下单组件进来，怎么办？核心思想就是解耦，但是又不仅仅是解耦。比如从解耦层次上，可能是只做数据层解耦，样式定死，支持一部分样式相同的组件的快速部署。又可能是样式、数据同时解耦，还可能是组件级别解耦，业务方根据协议生成组件，交付下单页面渲染布局。这里可以插一句，内聚/解耦的思想，是业务开发的核心方法论。业务开发面对底层开发在跟你炫耀 OpenGL，xx 算法模型，xx 编译原理的时候，可以先说你说的我也略懂，然后再问一句，那么，你懂xx业务解耦/组件化/动态布局/行业赋能/业务大脑吗？好，到第二层元元方法就为止了吗？其实不止。必然会有第三层，元元元方法，比如解耦要解到什么地步。假设你确定了这个下单页面可以解耦到组件层级，那明年呢？明年组件层级够用吗？这是时间维度。空间维度呢？换商品详情业务，解耦到什么层级呢？假设我们说商品详情业务可以解耦到数据层级，那么为什么下单可以解耦到组件层级，商品详情业务只能解耦到数据层级？能不能创建出一个推论模式，通过几个条件来判断一个业务究竟能解耦到哪个层级？前面说的都是业务维度，再从技术一点的维度来说，移动 App 页面开发总共可以归纳为几种形式的解耦，这些解耦各自有几种技术方案来实现。能否把解耦这事情也抽象成一个方案，使得一个业务只需要很低的开发/接入成本就可以切换成解耦型方案？事实上，Weex/Rax/H5也基本等同于是一个直接可插入的组件级别解耦方案了。只是这种大型通用的技术方案，已经不能称之为技术方案了，大家习惯性地把他看成了一个可以吃十几年饭的技术栈。但当我们缩小通用性领域，提高对某一类问题的专业度和适用度的时候，我们必然可以得到一个好的行业解决方案。第四层…好了，不说了，事实上抽象到第三层已经适用大多数场景了。但这并不意味着，第三层的元元元方法很少，事实上，很多。当我们在讨论 n+1 层的元方法的时候，我们必然是舍弃了 n 层中的一些信息，来获取n1，n2，n3….中的一些公有的共同点。那么，舍弃A、B、C，取 D，和舍弃A、C、D，取 B，他们得到的 n+1层的元方法都是不一样的。所以，元方法无穷无尽，每上一个维度，他的方法空间的大小也会膨胀一个维度。从一个二维的平面顿时变成了一个三维的空间。所以，抽象的世界比真实世界更复杂，只要我们未曾停下对真实世界、传统业务的扩张和改造，抽象的空间永远存在，人的思考永远有价值。结尾来一个类似自举一般的奇妙总结。这篇本身，也是一个元方法。