软件架构

作者：京东科技  倪新明设计用意的传播是架构可视化关注的重要维度，在技术计划评审过程中不可避免的会呈现各种各样的架构图或设计图，这些图形化表述在设计用意传播成果层面体现不一，本文从图形化的视角为软件架构图的评审关注点提供了参考。 注：对于架构及架构可视化参考文章 《 探寻软件架构的实质，到底什么是架构？》 《 软件架构可视化及C4模型：架构设计不仅仅是UML》 1 准则•明确的主题：架构图要表白的用意明确，比方是容器图、组件图还是部署图 •统一的形象层级：保持一致的形象层级，不应超过2个以上的档次变动 •粒度适合的范畴：不应试图在一张图表白“所有的货色”，每张架构图聚焦于本身职责边界的范畴 •清晰的图例阐明：对架构图色彩、形态等有明确的图例，以不便浏览导航 •图形色彩不宜太多：过多色彩减少认知老本，倡议不超过 4 种 •图形元素不宜太多：过多图形元素减少认知老本 •明确的连线关系形容 2 评审检查单如同上线检查单和开发检查单，针对于软件架构图的评审制订一套检查单同样具备价值。不管架构设计者，还是参加设计评审的开发人员，对于形式各异的 “架构图” 是提供通用的参考关注点，以便干系人更多、更深刻、更高效、更有针对性的获取架构图的更多信息。 2.1 通用查看项架构图是否具备题目? 是否可能了解架构图的类型是什么？ 是否可能了解架构图的范畴是什么？ 架构图是否有图例？ 2.2 元素架构图中每一个元素是否有名字？ 是否可能了解架构图中每个元素的类型？ (比方，形象级别，软件系统？容器？组件？等等) 是否可能了解架构图中的每个元素是做什么的？简要形容信息？ 是否可能了解与该元素相干的技术选型（适宜表明技术选型的元素） 是否可能了解架构图中应用的所有缩写/简称的含意? 是否可能了解架构图中元素应用的所有色彩的含意 是否可能了解架构图中元素应用的所有形态的含意 是否可能了解架构图中元素应用的所有图标的含意? 是否可能了解架构图中元素应用的所有边框款式的含意? (比方，实线 vs 虚线) 是否可能了解架构图中应用的所有元素大小的含意? (比方， 小框 vs 大框 ） 2.3 关联关系架构图中的每条线是否有形容关系含意的信息? 是否可能了解架构图中的每个关联关系（适宜表明技术选型的场景）的技术选型是什么？ (比方，过程间的交互的协定) 是否可能了解架构图中的关联关系的简称或缩写？ 是否可能了解架构图中的连线色彩的含意？ 是否可能了解架构图中的连线箭头的含意? 是否可能了解架构图中的连线款式的含意? (比方，实线 vs 虚线) 3 结语本文形容了软件架构图的一些评审关注点，其实不只是评审的视角，对于任何一个图形化的软件系统架构或设计表诉，如何可能疾速的理解其要表白的用意至关重要，对于设计者而言如何疾速传递架构设计信息并于干系人达成统一也至关重要。

研发工作重，手动同步状态和信息，分身乏术； 信息不通明，跨职能成员协调难、沟通老本高； 负责人到任，我的项目细节和代码信息却无从理解； …… 传统研发流程中，机械反复和信息孤岛或成为妨碍高效合作的头等因子。数字化与信息化的浪潮袭来，基于零碎和工具优化治理形式，构建数据闭环和流程自动化是研发提效的主旋律。 本文将从需要痛点解析和解决方案倡议两个方面，对研发效力优化开展解读，帮忙企业更好地打造坚硬、可继续倒退的研发生态。 一、研发流程治理中，企业的要害需要和痛点是什么？01 五个要害需要企业研发流程治理的五个要害需要别离是平安、自主可控、高效、低成本和可拓展。 安全性。包含代码平安、数据安全等。企业能够应用独立的代码仓库、依赖服务/数据可私有化等进步安全性。自主可控性。企业的外围业务应自主可控、不受限于内部；常通过可扩大的、可信的开源组件提供本人的服务实现。高效性。继续通明的研发流程是高效运行的低线。企业应建设无效的麻利项目管理机制，并联合DevOps进行继续集成与构建，谋求更高效的研发流程治理。低成本。我的项目研发要把资源用在刀刃上——通过正当的资源调配，产生尽可能低的附加老本，将无限的资源施展出最高性价比。可扩展性。满足当下技术须要的同时，企业还该当与可扩展性共成长，将可继续倒退贯彻到底。02 人治治理痛点人治管理模式下，研发流程治理非常灵活，但也存在诸多限度：我的项目信息不通明、代码同步滞后、状态更新消耗时力、信息传递易出错等等； 更重要的，我的项目信息和研发继续输入难以造成良性闭环，信息孤岛极大地限度了治理优化的下限。 其次，因为个体能力差异和能力阈值限度，忽略和谬误总是在劫难逃；南征北战的新手如若不足趁手兵器，也无奈保障高效交付高质量成绩。 除此之外，随着研发效力越来越受企业器重，研发流程治理也延长出更多的诉求： 有没有一种更稳固、可控的治理形式？企业如何依据本身状况定制计划，解决问题？哪些可借鉴的流程治理教训可减速突破难关？如何实现低成本、高效益的研发流程优化？在信息化的旅程中，更多基于人治的治理痛点和需要逐步浮现，企业也开始探究更好的研发流程治理方法和计划。 二、基于SaaS的研发流程治理计划许多实践经验发现，小规模研发团队的效率有时会更高。因为团队越大，部门越多，同步和沟通就变得复杂，再加上不足适合的工具佐助，协同老本便会大大增加。 相比之下，应用零碎/工具搭建流程闭环，或者是更高效的治理形式。而基于零碎提效的外围就是解决协同问题——代码协同、我的项目协同，以及代码和我的项目间的协同。 01 代码协同工具——GitLab对所有研发型企业来说，其外围资产就是代码，而云版GitLab能够满足代码治理、CI/CD、常识治理等需要。小规模团队应用云版GitLab，甚至能够不须要Jenkins或运维团队；如果想要进行代码私有化治理，能够思考托管版的GitLab。 同时，GitLab还领有丰盛的拓展能力，比方Jenkins、镜像仓库、maven仓库、K8S集成等等，对于买通研发全流程有显著意义。 02 容器化工具——Kubernetes随着研发团队的规模逐步变大，具备业余的运维团队，须要更多的资源协调能力时，企业可能会思考抉择容器化工具如Kubernetes。 在GitLab应用K8S集成能够实现主动编排，让部署容器化利用简略又高效。 代码是研发流程中最重要的产出，而GitLab以代码为外围，可能以极低的代价（甚至无需运维老本）实现简略的CI/CD流程，还能以私有化部署解决代码治理问题，晋升代码协同治理的效率。 显然，GitLab解决了局部的继续集成问题，然而在定制化我的项目研发流程和我的项目信息协同方面，却不肯定能满足企业需要，因而咱们须要一个可将两者联合的研发流程治理计划。 三、精简的研发全流程治理计划：LigaAI+GitLabLigaAI是新一代智能研发合作工具，通过AI赋能研发合作，解放人工机械工作，让人工智能成为企业生产力的一部分。 LigaAI解决我的项目信息协同问题，而GitLab通过DevOps解决代码协同问题；二者的集成联合可进一步实现我的项目和代码的无效协同，最终达成三个层面的研发效力晋升指标。 01 LigaAI+GitLab，如何实现「我的项目-代码」协同？LigaAI与GitLab的集成实现了我的项目信息和代码信息的双向同步。研发团队能够间接在LigaAI查看GitLab的代码提交和合并申请记录，还能间接创立分支、提交合并申请，疾速轻松地实现代码治理。 实现集成后，应用LigaAI丰盛的工作表组件，研发管理者可在工作台清晰地理解成员效力与代码提交状况，实现研发效力可视化，更及时地作出布局调整与治理。 通过配置【LigaAI-智能助理】，执行以创立Git提交为触发节点的主动执行规定，自动化研发合作流程，打消更新、同步和告诉等简单机械的工作； 或者应用LigaAI IDE插件中的模板，快捷提交代码并主动提取关联工作信息，缩小反复操作，开释更多生产力。 02 LigaAI+GitLab，如何实现研发流程可拓展性？LigaAI反对多种内部集成形式，如工具集成开发、丰盛的Open API和WebHook配置等，串联跨零碎/工具的我的项目和代码信息，赋能企业打造研发全流程的信息闭环。 通过形如「LigaAI + GitLab + Jenkins + K8S + IDE插件 + 飞书WebHook」的拓展利用，在实现代码治理和项目管理的同时，还能够借助人工智能等信息化工具，建设开发信息标准、晋升代码品质、构建自动化研发流程，并造就弱小的可拓展能力、大规模部署能力和容器化治理能力，最大水平地晋升研发效率。 Liga总结研发效力优化与晋升是企业降本增效的重要命题。与人治治理相比，基于零碎的研发流程治理办法更加合乎企业定制化治理和低成本转型的需要。 「LigaAI+GitLab」的精简化流程治理计划可能在实现我的项目协同和代码协同的同时，买通我的项目信息与研发继续输入的壁垒，实现我的项目与代码间的协同，并通过丰盛的可拓展计划打造研发全流程数据闭环，高效赋能研发团队稳步晋升。 对于 LigaAILigaAI是新一代智能研发合作平台。咱们以人工智能技术为外围，致力于通过AI场景化繁为简，晋升合作效率，赋能宽广研发团队。 从开发者的具体工作场景登程，LigaAI通过人工智能将开发者们从繁冗琐事中抽离进去，为其提供简洁、智能的合作体验，也为不同类型的组织提供数字化、个性化、智能化的我的项目合作平台。 理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发合作平台，在线申请体验咱们的产品。

原文：Clean architecture for the rest of us 作者：Suragch 这是一篇介绍性文章。如果你是一名高级软件工程师，能够到此为止了，这篇文章不适宜你。这篇文章是写给那些像我一样的一般程序员的，他们写着乌七八糟的代码，创立着像意大利面一样凌乱的架构，但却对构建洁净的、可保护的、适应性强的货色很着迷。 前言我通常不购买计算机相关的书籍，因为它们切实是过期的太快了。还有就是，反正这些书中信息在网上都能够查失去。但在一年前，我浏览了 Robert Martin 编写的 Clean Code，这本书实在的帮我改善了开发软件的形式。所以，当我看到同一作者另外一本书《Clean Architecture》出版的时候，便毫不犹豫的买下了它。 和 Clean Code 一样，Clean Architecture 中讲述了大量经的起工夫考验的准则，这些准则实用于任何人编写的任何代码。如果你在网上搜寻书名，会发现有些人并不认同作者的观点。显然，我不是要在这里批评他。我只是晓得 Robert Martin （又名 Uncle Bob）曾经从事编程超过50年，而我没有。 只管这本书了解起来有点艰难，但我会尽最大致力，把书中的重要概念加以总结和解释，让普通人也可能了解。作为一名软件架构师，我依然在一直学习成长，所以，请以批评的眼光浏览我写的货色。 什么是 clean architecture?架构 (Architecture) 是指我的项目的整体设计，是代码放入类(classes)、文件(files)、组件(components)、模块(modules) 的组织构造，以及这些代码单元之间互相关联的形式。架构定义了应用程序在哪里执行外围性能，以及这些性能如何与数据库、用户界面等事物进行交互。 Clean 架构是一种易于了解、能够随着我的项目倒退灵便扭转的我的项目组织形式。这不是随随便便就能够办到的，须要无意识的布局。 Clean architecture 的特点构建一个易于保护的大型项目的秘诀是：将类或文件拆分到不同的组件中，每个组件都能够独立于其余组件进行批改。让咱们用几张图片来阐明这一点： 下面的图片中，如果想用刀代替剪刀，你须要做什么？你必须解开连贯到笔、墨水瓶、胶带和指南针的绳子。而后你再将这些物品从新系到刀上。兴许这对于刀来说是能够了。但如果钢笔和胶带说：“等等，咱们须要剪刀。” 所以当初笔和胶带不能失常工作了，不得不在做扭转。这个扭转反过来又会影响那些连贯到它们下面的相干物体。 一团糟。 比照下图： 当初咱们应该如何替换剪刀呢？咱们只须要从便当贴上面拉出剪刀的绳子，而后把系在刀子上的新绳子插进去。容易多了。便当贴不在乎，因为绳子甚至没有绑在它下面。 第二张图所代表的架构显然更容易扭转。只有便当贴不须要被常常的更换，这个零碎就很容易保护。同样的，这种架构能够使软件更易于保护和变更。 内圈是应用程序的畛域层 (domain layer) ，用来搁置业务规定。咱们所说的“业务”不肯定是指公司，它只是意味着你的应用程序的实质，即代码的外围性能。例如：翻译应用程序的外围性能是翻译，线上商店的实质是要发售商品。这些业务规定通常相当的稳固，因为你不太可能常常扭转利用的实质。 外层是基础设施层 (infrastructure layer)，包含 UI、数据库、网络 API、以及软件框架之类的货色。绝对于畛域，这些更容易发生变化。举个例子，你更有可能更改 UI 按钮的外观，而不是更改贷款的计算形式。 畛域和基础设施之间设置了一个显著的边界，目标是让畛域对基础设施毫无感知。这意味着 UI 和数据库依赖业务规定，但业务规定不依赖 UI 和数据库。这使它成为一个插件架构 (plugin architecture)，无论 UI 是一个网页、桌面应用程序、还是挪动利用都没有关系；数据是存储在 SQL、NoSQL 还是云端也没有关系，畛域基本就不关怀。这使得更改基础设施变得非常容易。 ...

文｜吴成辉（花名：清霄 蚂蚁团体高级技术专家) 校对｜陈真、庄晓丹、冯家纯 本文 6250 字 浏览 11 分钟 ▼ 咱们一起回顾下监控下层业务已经面临的问题： 烟囱式的监控剖析反复建设在技术危险畛域，一度有超过 5 个零碎在做监控剖析的能力建设，大抵逻辑根本都是拉监控的 Raw Data，做根底的聚合、剖析解决后（相似同环比、阈值类的形式），依据一些以后的场景输出，联合一些算法能力，得出一个论断并触发一系列的 Action。相似这种烟囱式的监控剖析场景，都是比拟高级的反复建设，不足智能化、体系化。 SRE 教训标准化积淀的问题在剖析场景里也面临 SRE 教训无奈标准化积淀复用的问题，什么是 SRE 教训？拿交易付款上涨来举例，如果以后交易付款上涨 10%，SRE 通常有这么几个剖析门路，首先看下淘宝交易是否上涨（起源），再看交易创立，收银台渲染是不是上涨等，这一类咱们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何依据以后故障状况决策进行切流、限流等复原措施，咱们称为剖析后置操作。 长尾需要比方比拟常见的，算多数据之间的成功率，流量损耗等等需要，通过产品化解决的老本十分高，而且用户不能疾速批改、定制相干能力。 同时咱们看到以后监控零碎本身面临的问题： 监控的数据应用简单蕴含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。 监控服务不够凋谢如何动静日志荡涤计算、如何做剖析后的时序存储、监控的时序检测能力如何复用等等。咱们须要把监控的数据、能力齐全服务化进去。 高效的可编程代码化平台缺失没有一个高效平台帮忙 SRE 先积淀教训、再促成教训的标准化、复用，最初产品化。 基于下面问题，咱们提出了 MaaS 的构想（Monitoring as a Service), 监控能力服务化，凋谢、交融监控能力到技术危险各个领域，疾速实现 SRE 场景建设，积淀可复用能力，次要蕴含以下 4 个阶段指标： 1.凋谢服务把监控的计算、存储、算法、视图等等能力凋谢进去。 2.外围共建几个重点的技术危险畛域场景，比方变更进攻、压测引流、无损注入、定位应急等等。 3.促成服务的标准化积淀，让更多的场景能够复用、独特建设这部分的能力。 4.解决“监”与“控”之间的链接问题。 （咱们的这里的 AIOPS 更多指的是 一系列专家教训的汇合、积淀、继续保护优化） PART. 1 平台技术概览能力服务化 监控的服务化能力整体蕴含这么几局部，数据服务化、配置服务化、计算、存储服务化、算法服务化、告诉、云原生服务化等等，也包含一些内部能力集成比方音讯缓存等等。 我简略举两个服务化的例子来介绍下什么是服务化： 比方视图服务，当某个变更发动后，这个变更关联的 100 个利用指标、20 个业务指标中的 10 个指标呈现了问题，这个时候，咱们须要动静为这个 10 个指标创立一个数据视图，来剖析业务影响范畴，这个时候就会用到咱们的视图服务。 ...

*导读：畛域驱动设计（Domain Driven Design - DDD）起源于2004年Eric Evans出版《畛域驱动设计》，相比于在国外IT圈享有盛誉且卓有成效不同，国内IT圈理解DDD的人很少，落地实际的少之又少。最近几年随着微服务架构的遍及和中台的衰亡，DDD也成了各大技术论坛和微信公众号文章里常常谈起的话题。* DDD的热度是起来了，但业界介绍DDD的材料大多偏实践，不足生产我的项目可借鉴的实践经验。因而大多人读了很多DDD资料后还是一脸懵，怎么掂量DDD带来的价值？老板能批准搞DDD吗？什么样的业务和团队适宜DDD？DDD跟互联网强调的小步快跑疾速迭代能搭吗？如果要实际DDD产研团队都要做些啥？研发写代码跟平时有什么不一样？本文联合百度爱番番产研团队在过来一年多经验的从摸索、推广到全面落地DDD的过程，尝试答复上述问题，力求给大家带来一些借鉴意义。 全文约9500字，预计浏览工夫25分钟。 1  初心：以客户为核心，产研团队如何高效交付需要百度爱番番围绕营销拓客和销售提效帮忙企业收集、裁减、荡涤、造就、跟进和转化线索。一方面爱番番的业务特点是典型的企业级（ToB）业务，具备肯定的复杂度。业务对象多，单个业务对象提供的性能多，单个性能面向的场景多，业务对象之间组合进去的业务流程多。并且会随着交付的性能越多而变的越简单。另一方面产品处于爬坡阶段，性能须要疾速迭代交付到客户，从而疾速取得客户的反馈。产研团队在资源肯定的状况下如何高效交付更简单的需要成为了主要矛盾。 剖析以后阶段需要迭代过程中的问题，能够总结为以下几类问题： 业务逻辑不能从产品团队精准传递到研发团队，有时研发进行了一段时间开发才发现需要了解有偏差，导致须要从新跟产品经理探讨需要。产品团队和研发团队对于业务复杂度没有的意识不对立，产品经理认为一个需要的开发不难，理当在较少工夫内开发结束。研发团队面对需要增长和变动时，不足对业务逻辑的形象，往往开发一个须要点须要改变多处，容易出错且开发效率低，代码维护性差。需要文档和代码逻辑不匹配，线上性能的业务逻辑为什么实现成那样没有根据可查，畛域常识得不到积淀，团队得不到可继续成长。2  摸索：找到适宜的开发模式上述问题集中体现在两个方面，一是产品属于企业应用类，性能自身简单，如何让产研团队疾速了解业务、疾速交付。二是如何让畛域常识可能比拟精确的失去开发实现，让代码有比拟好的可维护性。借鉴业内解决简单企业级软件的开发教训，加上局部团队成员已经有过DDD应用的教训，团队决定尝试使用DDD设计思维来领导产研团队的日常需要迭代。 2.1  DDD是啥？DDD是一种围绕领域建模来解决简单业务交付的设计思维。读者无妨自问几个问题，什么是简单？什么是领域建模？ 1. 什么是简单？如何了解简单？简单可能是现状业务就简单，也可能是业务日渐演变成简单。简单来自规模在变，比方几个业务对象的逻辑不简单，几十上百个业务对象就会变得盘根错节。简单来自结构化有余，比方下图所示，结构化的中国结比非结构化的意大利面更有序、易于大脑了解。此外，一旦协同方多了，如何协同不同团队实现软件交付也是一种简单。 2. 什么是领域建模？畛域模型跟技术毫无关系，而是为了更有结构化的拆解和表白业务逻辑。业务逻辑来自事实世界里的具体场景，波及可视画面、操作动作和流程。要精确表白业务逻辑须要先讲清楚每个概念是什么，再建设概念之间的分割，基于这些关系再组合出更多的流程。概念、分割、流程就是畛域模型。围绕畛域模型去表白业务时也自然而然地把技术实现细节拆散进来了。后续代码实现就是将业务架构映射到零碎架构的过程，当前业务架构调整了能疾速的调整技术架构。 3. DDD中的畛域如何了解？DDD中示意业务逻辑的畛域概念是：实体、值对象、畛域服务、畛域事件。这意味着所有畛域逻辑都应该在这四种对象里，对立称为畛域模型对象，这将极大缩小业务逻辑的蔓延。引入聚合进一步封装实体和值对象，让畛域逻辑更内聚，起到边界爱护的作用。聚合的引入使得业务对象间的关联变少。如何设计聚合见上面实际局部。围绕聚合的操作引入工厂和资源库。工厂负责简单聚合的创立，资源库负责聚合的加载、增加、批改、删除。聚合内的实体状态变更通过畛域事件来推动。引入应用服务，对畛域逻辑编排、封装。供下层接口层调用。一个应用服务就是一次编排，一次编排就是一个用户用例。4. DDD畛域概念具体解释和举例 2.2  DDD如何发展？DDD蕴含策略设计、战术设计、技术实现三个局部。策略设计侧重于高层次、宏观下来划分限界上下文，而战术设计则关注应用建模工具来细化上下文，通过畛域模型来表白业务。技术实现次要通过分层架构来隔离畛域模型代表的业务逻辑和技术细节。一个整体过程大抵包含：宏观划分各畛域 → 畛域内划分限界上下文，定义上下文之间的关系 → 上下文内剖析业务，辨认畛域概念，定义适合的畛域概念 → 通过分层架构实现编码，并验证畛域模型的合理性，必要时从新回到后面步骤重构畛域模型。 1. 策略设计策略设计是团队领导层或业务负责人关怀的，该步骤须要针对产品愿景、业务要解决的问题域，布局外围域、通用域、撑持域，做适合的资源投入。 1. 什么是畛域和限界上下文？畛域代表事实世界的特定问题和解决方案的汇合，比方销售畛域、营销畛域。DDD里的限界上下文（Bouded Context）是对畛域的软件实现，比方线索零碎、商机零碎就是销售畛域内的限界上下文。限界上下文定义了解决方案的显著边界，边界里的每一个畛域概念，包含畛域概念内的属性和行为都有非凡含意。出了限界上下文这个边界这层含意就不复存在。 2. 如何划分限界上下文？1：依据相关性做归类。个别是优先思考性能相关性而不是语义相关性，比方创立订单和领取订单都是订单语义，但性能相差比拟大，应该划分为两个限界上下文。 2：依据团队粒度做裁剪、依据技术特点做裁剪。一些通用的技术性能应该尽可能归拢到一个限界上下文，比方每个业务限界上下文都有监控，但监控能力应该归拢到监控限界上下文。 3. BC与微服务什么关系？微服务是蕴含高度相干性能的一个开发部署单元，有本人的技术自治性包含技术选型、弹性扩缩容、公布上线频率等，有本人的业务演变自治性。BC是依据畛域逻辑的内聚状况造成的一个整体。一个微服务能够蕴含一个或多个BC，到底蕴含几个？须要依据团队大小、BC复杂度和技术个性来定。 2. 战术设计DDD设计思维里领域建模是最外围的一步，该阶段次要指标是提炼和定义出畛域模型和之间的关系。 1. 领域建模建模就是设计的过程，建模的过程就是梳理、走查业务逻辑，拆解为要解决的问题和波及的业务场景、业务流程、业务概念，在这个过程中造成对应的畛域概念。 如果团队对于业务比拟生疏适宜采纳事件风暴办法进行梳理；如果团队对业务比拟相熟，如果业务流程绝对简略，则能够采纳四色建模法进行业务梳理。采纳这些剖析业务的办法能够保障产研团队对业务逻辑的了解在一个程度上。 2. 业务逻辑的显性表白在实现了实体和值对象的设计后，有的时候会发现有些概念其实在畛域上是存在的，但设计和代码里没有Class来体现，可能仅仅是一个根本类型参数加上散落的对该参数的判断测验逻辑，这个时候还须要思考应该把这个概念显性化，定义专门的Class并蕴含相应逻辑，入出参以相应Class为类型。凡是业务代码逻辑蕴含了一堆if-else，这时候须要思考尽可能给这段逻辑建模成一个畛域概念。 比方CRM零碎里判断一条线索是否为推广线索须要看线索的渠道属性是否来自推广平台，那么比拟好的形式是这段逻辑用"推广线索"这个概念来显性表白，而不是吞没在代码里不容易了解和保护。 3. 对立语言为了解决业务逻辑连接的问题引入了对立语言。每个业务名词的含意具备明确的定义，产品和研发都统一认识。没有对立语言的沟通重大不足效率。比方CRM线索的概念，没有对立语言的时候每个人的了解不一样，有的人了解为有过征询记录的访客是线索，有的人了解为留下过联系方式的访客是线索，有的人了解为有购买志愿的访客是线索等等。 有了对立语言形容，每个概念就有了明确定义，能够节俭十分大的沟通交流老本。并且这个概念也同样利用在相干的需要文档、设计文档、代码编写中。每个概念从引入到日常交换，从需要文档到代码实现都有了统一的表白，代码实现和需要形容的真实度高，可了解性和可维护性就变好了。 3. 技术实现1. 分层架构为了让代码实现围绕畛域模型发展，尽量升高业务代码和纯技术选型代码的耦合，DDD引入了分层架构。确保了最外围的畛域层不依赖其余层，反过来让畛域之外的代码依赖畛域代码，升高了技术升级带来的影响。 2. DDD框架框架内定义不同畛域概念须要实现的接口，比方实现了聚合根接口的实体类就成为了聚合的根实体。定义了异样治理标准，不同的分层应该抛出什么类型的异样。定义了数据拜访的资源库接口等等。 3. 畛域事件畛域事件是对畛域内产生的流动进行的建模，即聚合内的实体状态变动的一个载体。DDD提倡限界上下文间尽量解耦，尽可能应用公布订阅畛域事件的合作模式进行上下游解耦。 2.3  DDD vs 数据模型驱动传统的业务开发模式里，研发受到关系型数据库设计范式、ER图等影响深远，在做软件具体设计过程中往往先想到如何设计对应的表构造，由此倒推出业务逻辑代码该如何组织。这就是典型的数据模型驱动设计，或者叫面向数据表设计编程。数据模型设计关注的是数据存储，数据尽量不要冗余，管制表数量不收缩，更多思考数据的扩展性，比方新加一个字段尽量不要在几张表都加，能用一个字段表白就不必两个字段。 这样的思维跟DDD是相同的，DDD优先思考畛域概念的业务语义表白，具备独立业务概念的货色会尽量形象成一个内聚的畛域对象。畛域对象不仅仅有属性，还有该有的行为。 因而，基于数据模型驱动的设计后果往往是： 1. 业务逻辑代码十分过程式，畛域实体只蕴含一堆属性，只是数据表的映射，没有业务行为。也就是常说的只有getter和setter办法的贫血对象。十分不足畛域概念的表白，业务逻辑散乱。比方值对象的设计在DDD里是一个类，在数据模型设计里往往是其余类的几个属性。 2. 聚合是DDD最小的复用单元，粒度更粗。数据模型设计里畛域实体的数量跟表数量一一对应，数据表是最小的复用单元，粒度太细。导致业务逻辑对应的实现类须要拜访很多的畛域实体，实现类之间的调用关系发散而盘根错节。下图是贫血模型和DDD富血模型的区别。 ...

一、导读因为向麻利转型，软件架构图的应用规模曾经大幅缩减。即便有在应用软件架构图，它们往往也混淆不清。C4 模型由一系列分层的软件架构图组成，这些架构图用于形容上下文、容器、组件和代码。C4 图的层次结构提供了不同的形象级别，每种形象级别都与不同的受众无关。为了避免出现含糊不清的状况，能够在图中蕴含足够数量的文本和要害的图例。二、C4概念软件架构图是一种十分好的表达方式，能够用它们来表白你将如何构建一个软件系统（事后设计）或者现有的软件系统是如何工作的（回顾文档、常识分享和学习）。 然而，你所看到的大多数软件架构图很可能只是由凌乱的框和线组成。麻利软件开发宣言的一个副作用就是让很多团队进行或缩减了他们的图表和文档工作，包含应用UML。 当初，这些团队偏向于依附他们在白板上绘制的长期图表，或者应用通用的图表工具（如微软的Visio）。Ionut Balosin 在去年写了一篇叫作“软件架构图的艺术”的文章，他在文章中形容了一些常见问题，这些问题与不可了解的符号和不明确的语义无关。 含糊不清的软件架构图容易导致误会，这可能会拖慢一个优良团队的后退步调。在咱们的行业中，咱们真的应该致力创立出更好的软件架构图。多年来，我本人参加软件开发，并与世界各地的团队单干，基于这些教训，我建设了一个称之为“C4 模型”的货色。C4 代表上下文（Context）、容器（Container）、组件（Component）和代码（Code）——一系列分层的图表，能够用这些图表来形容不同缩放级别的软件架构，每种图表都实用于不同的受众。能够将其视为代码的谷歌地图。 要为你的代码创立地图，首先须要一组通用的形象来创立一种无处不在的语言，用来形容软件系统的动态构造。C4 模型应用容器（应用程序、数据存储、微服务等）、组件和代码来形容一个软件系统的动态构造。它还思考到应用软件系统的人。 第1 层：零碎上下文第1 层是零碎上下文图，它显示了你正在构建的软件系统，以及零碎与用户及其他软件系统之间的关系。以下是一个零碎上下文图的示例，形容了一个互联网银行零碎的零碎上下文： 银行的集体客户应用互联网银行零碎查看无关银行账户的信息并进行领取。互联网银行零碎应用银行现有的大型机银行零碎来执行此操作，并应用银行现有的电子邮件系统向客户发送电子邮件。图中的色彩示意哪些软件系统曾经存在（灰色）以及待构建的零碎（蓝色）。 第2 层：容器第2 层是一个容器图，将软件系统放大，显示组成该软件系统的容器（应用程序、数据存储、微服务等）。技术决策也是该图的要害局部。以下是互联网银行零碎的容器图示例。它显示了互联网银行零碎（虚线框）由五个容器组成：服务器端Web 应用程序、客户端单页面应用程序、挪动应用程序、服务器端API 应用程序和数据库。 Web 应用程序是一个 Java/Spring MVC Web 应用程序，它仅提供动态内容（HTML、CSS 和 JavaScript），包含组成单页应用程序的内容。单页面应用程序是一个运行在客户网络浏览器中的 Angular 应用程序，提供所有的网上银行性能。或者，客户能够应用跨平台 Xamarin 挪动应用程序拜访互联网银行的局部性能。单页应用程序和挪动应用程序都调用 JSON/HTTPS API，这是由服务器端运行的另一个 Java/Spring MVC 应用程序提供的。API 应用程序从数据库中获取用户信息（关系数据库模式）。API 应用程序还应用专有的 XML/HTTPS 接口与现有的大型机银行零碎进行通信，以获取无关银行账户或交易的信息。如果须要向客户发送电子邮件，API 应用程序还会调用现有的电子邮件系统。 第 3 层：组件第 3 层是组件图，将单个容器放大，以显示其中的组件。这些组件映射到代码库中的实在形象（例如一组代码）。上面是一个虚构的网上银行零碎的组件图示例，显示了 API 应用程序中的一些组件（而不是全副）。 两个Spring MVC REST 控制器为JSON/HTTPS API 提供拜访点，每个控制器随后应用其余组件拜访数据库和大型机银行零碎中的数据。 第4 层：代码最初，如果你的确想要，或者说有这个必要，能够放大个别组件，以显示该组件的实现形式。以下是一个虚构的网上银行零碎的UML 类图示例（局部），显示了组成MainframeBankingSystemFacade 组件的代码元素（接口和类）。 它表明该组件由很多类组成，实现细节间接反映了代码。我并不倡议创立在这种具体水平的图表，有时候你能够间接从大多数IDE 中获取它们。 ...

阿里妹导读：从十余年前的各种分布式系统研发到现在的容器云，从支撑原有业务到孵化各个新业务，企业的发展离不开统一的、与时俱进的技术架构。本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化，希望能够帮助更多企业的 IT 转型，利用云计算技术推动其成为市场竞争中的敏捷力量。进入 21 世纪以来，我们见证了企业分布式应用架构从 SOA (Service-oriented Architecture)，到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些玄学。 第一，企业 IT 系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业 IT 系统的复杂度会越来越高；第二，在计算机交互设计中有一个著名的复杂性守恒定律[1]。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？ 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。 本图来自 Bilgin Ibryam 的 twitter[2] 蜕变之痛：SOA2004 年，IBM 建立 SOA 全球设计中心，我作为研发 TL 和架构师参与了一系列全球客户的 pilot 项目，帮助 Pepboys, Office Depot 等国际企业利用 SOA 优化企业内部和企业间的业务流程，提升业务敏捷性。 当时的大背景是：随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的 IT 系统已经经过了数十年的演化，整个的技术体系变得异常复杂，并存着诸如主机系统上的 CISC/COBOL 交易应用，小型机 AS400 中的 RPG 业务系统，和 X86/Power 等分布式系统的 C/JEE/.Net 应用。 大量应用系统由三方供应商提供，一些系统甚至已经无人维护。而且随着业务迭代，一些新的业务系统被持续构建出来，由于缺乏合理的方法论指导，系统之间缺乏有机的链接，形成了若干的孤岛，持续加剧了 IT 架构的复杂性，无法支撑业务的发展诉求。这就仿佛各派高手为了帮助受伤的令狐冲，把异种真气输入体中，虽然短时间可以缓解伤势。可是多道真气无法融合，互相激荡，长时间下来会伤上加伤。 因此，企业 IT 所面临的首要挑战就是整合企业中大量竖桶型（silo-ed）的 IT 系统，支撑日益复杂的业务流程，进行高效的业务决策和支撑业务快速变化。 在这种背景下，IBM 等公司提出了 SOA（面向服务的架构）理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。 SOA 提出了一系列构建分布式系统的原则，这些思考直到今天也依然适用： 服务具备明确定义的标准化的接口。通过服务定义描述，将服务消费者（Service Consumer）和服务提供者 (Service Provider) 的实现进行解耦，并且服务应该采用 contract-first 而非 code-first 方式进行开发。服务间通信采用面向文档的消息而非特定语言 RPC 协议，一方面可以解决服务与实现语言的解耦，另一方面可以灵活选择同步或者异步的通信实现，提升系统可用性和可伸缩性；服务应该是松耦合的，服务之间不应存在时间、空间、技术、团队上的依赖；服务应该是无状态的，使得服务调用与会话上下文状态实现解耦；服务应该是自治和自包含的，服务的实现是可以独立进行部署、版本控制、自我管理和恢复；服务是可发现、可组合的。比如可以通过 Service Registry 进行服务发现，实现了服务消费者和服务提供者的动态绑定。业务流程中可以对来自不同系统的的业务服务进行编排组装。在初始构建 SOA 系统的时候，大多采用点对点的通信连接，服务调用和集成逻辑被内嵌在应用实现中。这种方式在服务数量比较少的时候，确实是一种简单和高效的开发方式。但其最大的问题是，随着服务规模的增长，服务之间通信愈发复杂，连接路径和复杂性会剧增，给服务治理带来巨大的挑战。 ...

SOA概念: 是一种粗粒度、松耦合服务架构，各服务间均需要基于ESB（Enterprise Service Bus，企业服务总线）进行消息通信微服务概念: 它是SOA的细粒度体现。将单体架构系统按照业务进行垂直切分成独立的服务，并独立部署、运行； 各服务间通常是基于RESTful API（同步）和消息队列（MQ，异步）进行通信。框架工具Spring Boot, Spring CloudDocker 容器主要解决的问题： 1、通过镜像的方式将应用和运行环境一起打包部署，能做到开发、测试、线上环境保持一致2、作为一种新的虚拟化技术，降低了传统虚拟化技术带来的成本Docker的安装: yum -y install docker相关概念:- 镜像: 镜像是一个只读的文件系统，包括应用文件、环境文件。它通常包含堆叠在彼此之上的联合分层文件系统。 一个Docker容器中往往有多个不同的镜像。镜像没有状态并且始终不会发生更改。- 自定义镜像, 及其两种方式 - 通过Dockerfile文件快速创建镜像, 编写Dockerfile文件，然后执行docker build命令创建镜像 - 使用docker commit 命令从容器创建一个新的镜像 - 仓库 - 本地镜像仓库 - 远程镜像仓库- 容器 - Docker 容器是Docker镜像的运行时实例。Docker 容器中包含Docker 镜像执行环境一组标准指令此概念借用自船运集装箱，它们定义了在全球运送货物的标准。Docker 定义了交付软件的标准。常用命令:- 登录Docker 镜像仓库: docker login [OPTIONS] [SERVER]- 搜索远程仓库镜像，如docker search centos表示搜索与centos相关的镜像: docker search [OPTIONS] TERM - 从远程仓库拉取镜像到本地，默认tag（版本号）是latest: docker pull [OPTIONS] NAME[:TAG|@DIGEST] - OPTIONS: -a :拉取所有 tagged 镜像 - 如：docker pull centos表示拉取最新的centos镜像到本地- docker rmi [OPTIONS] 镜像ID/仓库名:镜像名 - 删除本地仓库中的镜像 - OPTIONS： -f：强制删除- docker run [OPTIONS] [镜像ID/仓库名:镜像名] - 包含两步操作： 1、将镜像放到容器中2、启动容器，相当于docker start - OPTIONS： 1）-i：以交互模式运行，通常与 -t 一起使用简写为-it2）-d：以后台程序运行，并返回容器ID3）-p：指定端口映射，宿主机端口:容器端口4）–name：为容器指定一个名称 - docker run -it 镜像ID/仓库名:镜像名 /bin/bash可以进入docker容器中的命令行模式 exit 或 Ctrl+D 命令退出并销毁当前docker容器Ctrl+P，Ctrl+Q也可退出，且不会销毁docker容器 - 端口映射 - 命令格式： docker run -p 宿主机端口:容器端口docker run -P - -p：指定映射端口 -P：随机映射端口 - 1）使用 -P 标记时，Docker 会随机映射一个 49000~49900 的端口到内部容器开放的网络端口； 2）-p则可以指定要映射的IP和端口，但是在一个指定端口上只可以绑定一个容器。支持的格式有 hostPort:containerPort、ip:hostPort:containerPort、 ip::containerPort。 - 如：docker run -p 80:80 –name mynginx -p 80:80：将容器的80端口映射到主机的80端口 –name mynginx：将容器命名为mynginx - 如创建并启动mysql容器： docker run –name mysql -p 3306:3306 -v /var/lib/mysql/:/var/lib/mysql/ -e MYSQL_ROOT_PASSWORD=123 -d mysql:5.7其中 –name 指定容器以mysql命名, -p 指定端口映射，-v 指定挂载宿主机目录，-e 指定环境变量，-d 指定镜像- docker start/stop/restart <容器名或ID> - 启动, 停止, 重启(相当于停止+启动)- docker rm <容器名或ID> - 删除指定的容器，该容器必须已经停止运行- docker commit <容器名或ID> - 使用容器创建镜像- docker push [仓库名:镜像名] - 将本地镜像推送至远程仓库- docker ps [OPTIONS] - 查看容器 - 如： docker ps：查看正在运行的容器docker ps -a：查看所有的容器，包括已经停止的- docker images [OPTIONS] [REPOSITORY[:TAG]] - 查看本地有哪些镜像- docker logs <容器名或ID> - 查看容器日志- docker port <容器名或ID> - 查看容器端口映射情况- docker exec -it <容器名或ID> bash - 以交互模式进入正在运行的容器，输入 exit 则退出 ...

阿里妹导读：数据中心已成为支撑大规模互联网服务的标准基础设施。随着数据中心的规模越来越大，数据中心里每一次软件（如 JVM）或硬件（如 CPU）的升级改造都会带来高昂的成本。合理的性能分析有助于数据中心的优化升级和成本节约，而错误的分析可能误导决策、甚至造成巨大的成本损耗。本文整理自阿里巴巴高级技术专家郭健美（花名：希伯）在Java相关行业会议的分享，主要介绍阿里大规模数据中心性能监控与分析的挑战与实践，希望对你有所启发。作者简介：郭健美（花名：希伯），阿里巴巴高级技术专家，目前主要从事数据中心的性能分析和软硬件结合的性能优化。CCF 系统软件专委和软件工程专委的委员。大家好，很高兴有机会与 Java 社区的开发者交流。我的研究领域在软件工程，主要集中在系统配置和性能方面。软件工程一个比较常见的活动是找 bug，当然找 bug 很重要，但后来也发现，即便 bug-free 的程序也会被人配置错，所以就衍生出了软件配置问题。很多软件需要配置化，比如 Java 程序或 JVM 启动时可以配置很多参数。通过配置，一套软件可以灵活地提供各种定制化的功能，同时，这些配置也会对软件整体性能产生不同的影响。当然这些还在软件配置方面，来了阿里以后，我有机会把这方面工作扩展到了硬件，会更多地结合硬件比如 CPU，来看系统的配置变更和升级改造对性能、可靠性以及业务上线效果的影响。今天主要谈谈我在这方面的一点工作。阿里最有代表性的事件是“双 11”。这里还是用的17年的数据，左上角是双十一的销售额，17年大概是 253 亿美金，比美国同期 Thanksgiving、Black Friday、Cyber Monday 加起来的销售额还要多。当然这是从业务层面去看数据，技术同学会比较关注右边的数据，17年双十一的交易峰值达到 32.5 万笔/秒、支付峰值达到 25.6 万笔/秒。对于企业来说，这么高的峰值性能意味着什么？意味着成本！我们之所以关注性能，就是希望通过持续的技术创新，不断地提高性能、同时节省成本。双十一零点的峰值性能不是一个简单的数字，其背后需要一个大规模数据中心来支撑。 简单来说，阿里的基础架构的上层是各种各样的应用，比如淘宝、天猫、菜鸟、钉钉，还有云计算和支付宝等，这也是阿里的一个特色，即具有丰富的业务场景。底层是上百万台机器相连的大规模数据中心，这些机器的硬件架构不同、分布地点也不同，甚至分布在世界各地。中间这部分我们称之为中台，最贴近上层应用的是数据库、存储、中间件以及计算平台，然后是资源调度、集群管理和容器，再下面是系统软件，包括操作系统、JVM 和虚拟化等。中台这部分的产品是衔接社区与企业的纽带。这两年阿里开源了很多产品，比如 Dubbo、PouchContainer 等，可以看出阿里非常重视开源社区，也非常重视跟开发者对话。现在很多人都在讲开源社区和生态，外面也有各种各样的论坛，但是像今天这样与开发者直接对话的活动并不是那么多，而推动社区发展最终还是要依赖开发者。这样大规模的基础架构服务于整个阿里经济体。从业务层面，我们可以看到 253 亿美金的销售额、32.5 万笔交易/秒这样的指标。然而，这些业务指标如何分解下来、落到基础架构的各个部分就非常复杂了。比如，我们在做 Java 中间件或 JVM 开发时，都会做性能评估。大部分技术团队开发产品后都会有个性能提升指标，比如降低了 20% 的 CPU 利用率，然而这些单个产品的性能提升放到整个交易链路、整个数据中心里面，占比多少？对数据中心整体性能提升贡献多少？这个问题很复杂，涉及面很广，包括复杂关联的软件架构和各种异构的硬件。后面会提到我们在这方面的一些思考和工作。阿里的电商应用主要是用 Java 开发的，我们也开发了自己的 AJDK，这部分对 OpenJDK 做了很多定制化开发，包括：融入更多新技术、根据业务需要及时加入一些 patches、以及提供更好的 troubleshooting 服务和工具。大家也知道，18年阿里入选并连任了 JCP EC(Java Community Process - Executive Committee) 职位，有效期两年，这对整个 Java 开发者社区、尤其是国内的 Java 生态都是一件大事。但是，不是每个人都了解这件事的影响。记得之前碰到一位同仁，提到 JCP EC 对阿里这种大业务量的公司是有帮助，对小公司就没意义了。其实不是这样的，参选 JCP EC 的时候，大公司、小公司以及一些社区开发者都有投票资格，小公司或开发者有一票，大公司也只有一票，地位是一样的。很多国外的小公司更愿意参与到社区活动，为什么？举个简单例子，由于业务需要，你在 JVM 8 上做了一个特性，费了很大的力气开发调试完成、业务上线成功，结果社区推荐升级到 JVM11 上，这时你可能又需要把该特性在 JVM 11 上重新开发调试一遍，可能还要多踩一些新的坑，这显然增加了开发代价、拉长了上线周期。但如果你能影响社区标准的制定呢？你可以提出将该特性融入社区下一个发布版本，有机会使得你的开发工作成为社区标准，也可以借助社区力量完善该特性，这样既提高了技术影响力也减少了开发成本，还是很有意义的。过去我们做性能分析主要依赖小规模的基准测试。比如，我们开发了一个 JVM 新特性， 模拟电商的场景，大家可能都会去跑 SPECjbb2015 的基准测试。再比如，测试一个新型硬件，需要比较 SPEC 或 Linpack 的基准测试指标。这些基准测试有必要性，因为我们需要一个简单、可复现的方式来衡量性能。但基准测试也有局限性，因为每一次基准测试都有其限定的运行环境和软硬件配置，这些配置设定对性能的影响可能很大，同时这些软硬件配置是否符合企业需求、是否具有代表性，都是需要考虑的问题。阿里的数据中心里有上万种不同的业务应用，也有上百万台分布在世界各地的不同服务器。当我们考虑在数据中心里升级改造软件或硬件时，一个关键问题是小规模基准测试的效果是否能扩展到数据中心里复杂的线上生产环境？举个例子，我们开发了 JVM 的一个新特性，在 SPECjbb2015 的基准测试中看到了不错的性能收益，但到线上生产环境灰度测试的时候，发现该特性可以提升一个 Java 应用的性能、但会降低另一个 Java 应用的性能。同时，我们也可能发现即便对同一个 Java 应用，在不同硬件上得到的性能结果大不相同。这些情况普遍存在，但我们不可能针对每个应用、每种硬件都跑一遍测试，因而需要一个系统化方法来估计该特性对各种应用和硬件的整体性能影响。对数据中心来说，评估每个软件或硬件升级的整体性能影响非常重要。比如，“双11”的销售额和交易峰值，业务层面可能主要关心这两个指标，那么这两个指标翻一倍的时候我们需要买多少台新机器？需要多买一倍的机器么？这是衡量技术能力提升的一个手段，也是体现“新技术”对“新商业”影响的一个途径。我们提出了很多技术创新手段，也发现了很多性能提升的机会，但需要从业务上也能看出来。为了解决上面提到的问题，我们开发了 SPEED 平台。首先是估计当前线上发生了什么，即 Estimation，通过全域监控采集数据，再进行数据分析，发现可能的优化点。比如，某些硬件整体表现比较差，可以考虑替换。然后，我们会针对软件或硬件的升级改造做线上评估，即 Evaluation。比如，硬件厂商推出了一个新硬件，他们自己肯定会做一堆评测，得到一组比较好的性能数据，但刚才也提到了，这些评测和数据都是在特定场景下跑出来的，这些场景是否适合用户的特定需求？没有直接的答案。通常，用户也不会让硬件厂商到其业务环境里去跑评测。这时候就需要用户自己拿这个新硬件做灰度测试。当然灰度规模越大评测越准确，但线上环境都直接关联业务，为了降低风险，实际中通常都是从几十台甚至几台、到上百台、上千台的逐步灰度。SPEED 平台要解决的一个问题就是即便在灰度规模很小时也能做一个较好的估计，这会节约非常多的成本。随着灰度规模增大，平台会不断提高性能分析质量，进而辅助用户决策，即 Decision。这里的决策不光是判断要不要升级新硬件或新版软件，而且需要对软硬件全栈的性能有一个很好的理解，明白什么样的软硬件架构更适合目标应用场景，这样可以考虑软硬件优化定制的方向。比如，Intel 的 CPU 从 Broadwell 到 Skylake，其架构改动很大，但这个改动的直接效果是什么？Intel 只能从基准测试中给答案，但用户可能根据自己的应用场景给出自己的答案，从而提出定制化需求，这对成本有很大影响。最后是 Validation，就是通常规模化上线后的效果来验证上述方法是否合理，同时改进方法和平台。数据中心里软硬件升级的性能分析需要一个全局的性能指标，但目前还没有统一的标准。Google 今年在 ASPLOS 上发表了一篇论文，提出了一个叫 WSMeter 的性能指标，主要是基于 CPI 来衡量性能。在 SPEED 平台里，我们也提出了一个全局性能指标，叫资源使用效率 RUE。基本思想很简单，就是衡量每个单位 Work Done 所消耗的资源。这里的 Work Done 可以是电商里完成的一个 Query，也可以是大数据处理里的一个 Task。而资源主要涵盖四大类：CPU、内存、存储和网络。通常我们会主要关注 CPU 或内存，因为目前这两部分消费了服务器大部分的成本。RUE 的思路提供了一个多角度全面衡量性能的方法。举个例子，业务方反映某台机器上应用的 response time 升高了，这时登录到机器上也看到 load 和 CPU 利用率都升高了。这时候你可能开始紧张了，担心出了一个故障，而且很可能是由于刚刚上线的一个新特性造成的。然而，这时候应该去看下 QPS 指标，如果 QPS 也升高了，那么也许是合理的，因为使用更多资源完成了更多的工作，而且这个资源使用效率的提升可能就是由新特性带来的。所以，性能需要多角度全面地衡量，否则可能会造成不合理的评价，错失真正的性能优化机会。下面具体讲几个数据中心性能分析的挑战，基本上是线上碰到过的具体问题，希望能引起大家的一些思考。首先是性能指标。可能很多人都会说性能指标我每天都在用，这有什么好说的。其实，真正理解性能指标以及系统性能本身并不是那么容易。举个例子，在数据中心里最常用的一个性能指标是 CPU 利用率，给定一个场景，数据中心里每台机器平均 CPU 利用率是 50%，假定应用需求量不会再增长、并且软件之间也不会互相干扰，那么是否可以把数据中心的现有机器数量减半呢？这样，理想情况下 CPU 利用率达到 100% 就可以充分利用资源了，是否可以这样简单地理解 CPU 利用率和数据中心的性能呢？肯定不行。就像刚才说的，数据中心除了 CPU，还有内存、存储和网络资源，机器数量减半可能很多应用都跑不起来了。再举个例子，某个技术团队升级了其负责的软件版本以后，通过线上测试看到平均 CPU 利用率下降了 10%，因而声明性能提升了 10%。这个声明没有错，但我们更关心性能提升以后是否能节省成本，比如性能提升了 10%，是否可以把该应用涉及的 10% 的机器关掉？这时候性能就不应该只看 CPU 利用率，而应该再看看对吞吐量的影响。所以，系统性能和各种性能指标，可能大家都熟悉也都在用，但还需要更全面地去理解。刚才提到 SPEED 的 Estimation 会收集线上性能数据，可是收集到的数据一定对吗？这里讲一个 Hyper-Threading 超线程的例子，可能对硬件了解的同学会比较熟悉。超线程是 Intel 的一个技术，比如我们的笔记本，一般现在都是双核的，也就是两个 hardware cores，如果支持超线程并打开以后，一个 hardware core 就会变成两个 hardware threads，即一台双核的机器会有四个逻辑 CPU。来看最上面一张图，这里有两个物理核，没有打开超线程，两边 CPU 资源都用满了，所以从任务管理器报出的整台机器平均 CPU 利用率是 100%。左下角的图也是两个物理核，打开了超线程，每个物理核上有一个 hardware thread 被用满了，整台机器平均 CPU 利用率是 50%。再看右下角的图，也是两个物理核，也打开了超线程，有一个物理核的两个hardware threads 都被用满了，整台机器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情况完全不同，但是如果我们只是采集整机平均 CPU 利用率，看到的数据是一样的！所以，做性能数据分析时，不要只是想着数据处理和计算，还应该注意这些数据是怎么采集的，否则可能会得到一些误导性的结果。数据中心里的硬件异构性是性能分析的一大挑战，也是性能优化的一个方向。比如这里左边的 Broadwell 架构，是 Intel 过去几年服务器 CPU 的主流架构，近几年在推右边的 Skylake 架构，包含最新的 Cascade Lake CPU。Intel 在这两个架构上做了很大的改动，比如，Broadwell 下访问内存还是保持多年的环状方式，而到了 Skylake 改为网格状方式。再比如，L2 Cache 到了Skylake 上扩大了四倍，通常来说这可以提高 L2 Cache 的命中率，但是 cache 越大也不代表性能就一定好，因为维护 cache coherence 会带来额外的开销。这些改动有利有弊，但我们需要衡量利和弊对整体性能的影响，同时结合成本来考虑是否需要将数据中心的服务器都升级到 Skylake。了解硬件的差异还是很有必要的，因为这些差异可能影响所有在其上运行的应用，并且成为硬件优化定制的方向。现代互联网服务的软件架构非常复杂，比如阿里的电商体系架构，而复杂的软件架构也是性能分析的一个主要挑战。举个简单的例子，图中右边是优惠券应用，左上角是大促主会场应用，左下角是购物车应用，这三个都是电商里常见的业务场景。从 Java 开发的角度，每个业务场景都是一个 application。电商客户既可以从大促主会场选择优惠券，也可以从购物车里选择优惠券，这是用户使用习惯的不同。从软件架构角度看，大促主会场和购物车两个应用就形成了优惠券应用的两个入口，入口不同对于优惠券应用本身的调用路径不同，性能影响也就不同。所以，在分析优惠券应用的整体性能时需要考虑其在电商业务里的各种错综复杂的架构关联和调用路径。像这种复杂多样的业务场景和调用路径是很难在基准测试中完全复现的，这也是为什么我们需要做线上性能评估。这是数据分析里著名的辛普森悖论，在社会学和医学领域有很多常见案例，我们在数据中心的性能分析里也发现了。这是线上真实的案例，具体是什么 App 我们不用追究。假设还用前面的例子，比如 App 就是优惠券应用，在大促的时候上线了一个新特性 S，灰度测试的机器占比为 1%，那么根据 RUE 指标，该特性可以提升性能 8%，挺不错的结果。但是如果优惠券应用有三个不同的分组，分组假设就是关联刚才提到的不同入口应用，那么从每个分组看，该特性都降低了应用的性能。同样一组数据、同样的性能评估指标，通过整体聚集分析得到的结果与通过各部分单独分析得到的结果正好相反，这就是辛普森悖论。既然是悖论，说明有时候应该看总体评估结果，有时间应该看部分评估结果。在这个例子里面，我们选择看部分评估、也就是分组上的评估结果，所以看起来这个新特性造成了性能下降，应该继续修改并优化性能。所以，数据中心里的性能分析还要预防各种可能的数据分析陷阱，否则可能会严重误导决策。最后，还有几分钟，简单提一下性能分析师的要求。这里通常的要求包括数学、统计方面的，也有计算机科学、编程方面的，当然还有更重要的、也需要长期积累的领域知识这一块。这里的领域知识包括对软件、硬件以及全栈性能的理解。其实，我觉得每个开发者都可以思考一下，我们不光要做功能开发，还要考虑所开发功能的性能影响，尤其是对数据中心的整体性能影响。比如，JVM 的 GC 开发，社区里比较关心 GC 暂停时间，但这个指标与 Java 应用的 response time 以及所消耗的 CPU 资源是什么关系，我们也可以有所考虑。本文作者：郭健美阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。 ...

为什么需要架构可视化随着企业进行微服务架构改造，系统架构复杂度越来越高，架构变化日益频繁，微服务改造后的实际架构模型可能与预期已经产生了巨大差异，架构师或系统运维人员很难准确记忆所有资源实例的构成和交互情况；其次，系统架构在动态演化过程中可能引入了一些不可靠的因素，比如弱依赖变强依赖、局部容量不足、系统耦合过重等，给系统的稳定性带了极大的安全隐患。所以我们每次在面对系统改造、业务大促以及稳定性治理工作之前，都会通过梳理架构图的方式，呈现系统架构中个组件之间的交互方式，架构可视化能够清晰的协助我们识别架构中存在的问题以及建立高可用的系统。架构可视化后，可以给我们带来以下几点但不局限于此的优势：确定系统边界一张好的架构图，应该明确系统所包含的各个组件以及各个组件之间的核心调用关系，这些组件的集合就是系统的处理边界，系统架构的边界在一定程度上也反映了业务域的边界。架构问题识别基于高可用的架构准则，结合可视化的架构图，可以评估架构可能存在的安全风险，比如系统在容灾、隔离以及自愈维度下的健壮性。其次，一些架构链路可视化工具(比如鹰眼)在实际工作中确实大大提高了开发者排查与定位问题的效率。提高系统可用性有了系统架构的上下游依赖关系图，在故障发生时，开发人员可以借助依赖数据快速定位到问题的来源，极大缩短问题修复时间（MTTR）。借助架构图，我们还可以梳理出系统中存在的强弱依赖，在业务高峰期对弱依赖进行降级，或者针对系统依赖的各个组件进行故障模拟，以评测系统整体在面对局部故障的可靠性。常见架构可视化的做法我们熟知的架构图是静态的停留在PPT上的，很多时候我们的架构已经发生了非常大的变化，但是我们还在使用那张看上去很经典却早已过时的架构图。长时间使用与实际架构不符的架构图对线上架构的认知的危害是巨大的，我们需要在脑海中不断更新对系统架构的视图，以保持对系统架构的敏感度。每年的大促或者重大系统改造成为我们梳理系统架构、对架构进行重新认知的机会，此刻我们需要通过各种工具查看系统的各个组件分布以及不同组件的内部与外部的依赖关系，这种梳理架构图的方法是最常用的方式，权且称之为“手工绘制法”。手工经常干的事情，就有追求效率的同学使用计算机系统带来的自动化手段帮助自己做这件事情，比如我们常常看到的基于数据埋点的微服务可视化解决方案，这类架构可视化手段通常在分布式追踪、APM等监控领域使用较多，下图为某APM产品提供的应用维度架构可视化方案：我们称这种可视化方式为“埋点式感知法”，架构组件的识别是依赖关键的核心类检测与埋点，此种方案存在以下弊端：语言相关性：只要是系统埋点，与语言相关的特征基本就拜托不了，需要针对不同语言提供不同的依赖包；不易维护：因为是对核心类的检测，当组件包做了重大变更时，需要同步变更；不易扩展：因为是客户端识别方案，客户端一旦开放出去，新组件的支持只能等待用户更新组件；规模受限：客户端识别的另一个缺点是算法受限，服务端进行识别，可以借助大数据分析等手段更有效准确的识别；还有一种自动化架构感可视化方法，我们称之为“无界架构感知”，是一种语言无关性的架构识别方案，其采用采集用户主机上的进程和容器的元数据、监控数以及网路数据的最最基础的数据，在服务端构建架构图。架构可视化还能怎么做为了最大限度上降低用户进行架构可视化的成本，我们采用了应用无侵入的方式微服务进行可视化，通过采集进程数据与网络调用数据，构建进程间的网络调用关系，构建微服务的架构信息。用户只需要安装我们AHAS Agent探针，即可完成架构可视化操作；对于阿里云云原生系统，我们提供了自动化安装方式，而无需登录机器。如何让架构可视化更有效我们同样认为架构可视化的有效性跟人的认知层次有关，架构可视化的重点是确定该工具是否更好的支持自顶向下方法、自下而上方法或者两者的结合。开发者更关心应用维度上的架构，架构师或者管理者更关心整体系统架构。所以需要针对不用的使用者提供不同层次的架构可视化视角。理想的架构图需要支持宏观维度以及不断下钻下的微观视角，我们对架构进行了分层设计，目前分为进程层、容器层和主机层，后期我们可能会继续上扩或者下钻支持地域层或者服务层。下图为一台阿里云ECS部署了微服务应用安装AHAS探针之后的可视化三层架构界面：应对架构的可变性没有哪家科技公司的系统架构是一成不变的，系统架构会随着系统的版本迭代不断进行演化。所以对架构可视化操作，还需要具备随着时间的推移可对架构信息进行自动更新已经回溯的能力。在我们提供的架构感知产品中默认架构图会随着时间自动刷新，同时支持对历史的回溯，你可以选择历史中的某一刻查看架构信息，比如，重大版本的变更时，发布前与发布后的系统架构是否发生了违背一些高可用原则的问题，抑或排查是否出现了不该有的依赖问题。架构可视化的核心软件架构可视化的核心点是寻找在软件体系结构中有意义和有效的元素视图以及这些元素之间的关系。我们认为一款优秀的软件架构可视化产品应该帮助用户排除掉不重要的信息，给用户呈现出对他们有价值的视图，特别是在微服务架构下庞大而复杂的调用关系链场景中。这里面的核心点是有意义和有效，要做到这两点，首先需要识别什么是有意义和有效的元素和关系，我们在此领域做的事情归纳起来就是“识别”，识别机器上的每个进程是什么，发生的网络调用远端是什么，唯有知晓了这些元素是什么我们才有理由和依据来判断是否对用户有意义以及其在用户架构中的重要程度。架构可视化中的元素识别在梳理了大量架构图，我们发现用户关心的架构元素主要分为三类：1. 自己的应用服务；2. 应用对外部的资源依赖；3. 服务器本身的信息。 应用对外部资源的依赖通常以其它应用和通用中间件或者存储服务两种形式存在。故我们将需要识别的进程分为：应用服务和常见的组件服务（比如Redis、MySQL等），这些组件服务又分为用户自建的服务和使用公有云提供的服务，特别是对于Cloud Native应用来说，云服务的识别显得格外重要。目前，我们提供了20种阿里云云服务的识别以及包含MySQL、Redis、Tomcat等常见的21种三方服务组件，此组件库还在不断扩张中，目的就是最大限度的知晓架构中的元素到底是什么。图中展示了通过识别服务识别出来的Nginx、Redis组件以及阿里云中的Mysql服务和AHAS服务有了架构可视化还能做什么架构可视化不是目的，只是实现系统高可用性的手段。借助架构感知采集到的架构数据，在识别了用户使用的组件（我们对MySQL、Redis、MQ等的统称)后，我们借助这些组件以及与组件匹配的故障库，可以给用户自动推荐这些组件可能遇到的故障，配合我们提供的评测服务让用户更方便地对组件进行各种故障的模拟与演练，以提高系统的健壮性。其次，通过架构感知识别Java Application 应用，如果发现其负载较高，配合我们提供的限流降级（阿里巴巴开源的Sentinel商业版）功能，为服务的持续可用性保驾护航。借助架构感知进行系统限流配置我们对AHAS的定位是一款数据分析型的高可用保障产品，帮助云原生架构系统实现高可用能力的提升。架构可视化是我们给用户提供的高效运维和管控的窗口，我们期望通过丰富的云原生数据体系配合架构图的可视化以及可操作性，建立起以应用为中心的运维一体化平台。在未来，我们会加强与其它云服务的集成，比如监控、容器服务，以丰富架构感知的数据维度；其次，会在数据的深度挖掘和智能化消费上投入更多精力，真正让数据成为企业的核心价值，让数据成为保障业务的稳定性的利器。本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。