搜索[architecture]结果-低调大师优秀个人博客

App 组件化/模块化之路——Android 框架组件(Android Architecture Components)使用指南

面对越来越复杂的 App 需求，Google 官方发布了Android 框架组件库（Android Architecture Components ）。为开发者更好的开发 App 提供了非常好的样本。

2017-08-03

122Architecture 全面解读 - 第一篇全局解析+ADG+IM模块

上周五早上，风和日丽。小明和小强在上班路上相遇了。呀不好意思，来晚了，我们已经打烊了。不过呢，看在大家都热爱学习的份上，我们将会分享课程视频给大家。 Oracle自发布12.1之后，就一直声称要全面转云，在之后的三四年里，一直杳无音信，大家都在猜测，Oracle又在憋什么大招，果然，2017阳春三月，大招来了！今年三月份，在广大用户的热切盼望中，Oracle终于发布了12c Release2。与此同时，云和恩墨专家迅速投入到新特性的研究当中，在12.2发布不到2个月的时间里，并设计出了全球最新版的Oracle 12.2体系架构图。先来一饱眼福吧很多同学跟我们说，这张图信息量太大看不懂表示很绝望。为了让大家更好地学习，云和恩墨推出系列课程“全面解读Oracle 12.2的体系架构图” ，上周四第一课QQ群火热直播，反响热烈。接下来我们简要概括一下课时一的内容要点：体系架构图组成 Oracle 12.2体系架构图基于最基本的Oracle数据库访问模式，延伸出包含Active DataGuard，Sharding，Multitenant，Flex Cluster，Flex ASM等多个解决方案的模块。课时一主要介绍了整个图的内容组成，并展开详细解读了模块一（ADG+IM）的部分。在第一个模块，我们展开讨论了以下的内容要点： 1、在ADG中，逻辑standby和物理standby的数据同步与应用； 2、12.2中，支持ADG上部署IM列存储，并讨论了三种部署方案；（可参考以下文章：【12.2新特性】在Oracle Active Data Guard上部署列式存储） 3、Oracle的零数据丢失同步方案：Far Sync实例的配置； 4、在12.2中DG上的一些新特性，比如远程AWR，standby上的SQL tuning等，可参考以下文章：Oracle 12.2新特性掌上手册 - 第六卷 ADG的性能与诊断); 5、在12.2中IN-MEMORY的新特性，比如：join group，faststart等。好了话不多说，想学习的同学请观看视频。原文链接下载。不少朋友问讲师要ppt，实话实说，讲师（只有脑子）真没有ppt,不过倒有几张经典的参考图送给各位，为大家简单讲解一下。 reference picture1 根据白求恩对中国的Oracle用户使用Oracle数据库现状分析，在10g以前的版本中，有部分用户在使用裸设备作为数据库存储方式，11g以后已经很少见，12c已结没有人使用裸设备了。ASM和文件系统将成为最主要的两种文件存储方式，而ASM则是集群环境下的最佳存储选择。（了解白求恩请点击：Bethune，你最佳的运维小助手。） reference picture2 在12.2以前，ADG架构中，若有多个节点，则多个节点的RFS进程可以同时接收来自主库的日志，但在日志应用过程中，只有一个MRP进程进行，因此多个节点的日志应用的串行的。在12.2中，ADG中多节点standby，日志可以并行应用。会在每个节点都启动一个MRP进程。 reference picture3 最简单的Far sync的配置模式：在主库附近（实现同步的距离限制范围内）配置far sync实例，主库与far sync实例之间进行同步传输，far sync与备库之间进行异步传输，这样，即使主备之间的连接出现连接问题，主库的数据都在far sync实例中，实现数据零丢失。 Far Sync的高可用配置：虽然far sync提供零丢失的数据同步，但一切都会出故障，为了避免主库与Far Sync之间的连接出现问题导致数据丢失，在主库上配置两个Far Sync实例，当其中一个连接中断的时候，自动切换到另一个Far Sync实例。 Far Sync的扩展配置：在需要做主备切换的环境中，为了保证切换后的数据传输不受影响，在两个节点上都配置Far Sync实例，当然，在同一时刻，只有一个Far Sync实例处于活动状态，也就是与当前主库靠近的Far Sync实例处于活动状态。 reference picture4 在12.2的IM中，支持三种格式的数据存储：关系型数据，虚拟列和JSON格式。并且可以将JSON对象的虚拟列直接存放在IM的虚拟列，使得针对JSON对象的操作非常方便。注意，对于JSON的文档，一般要求文件大小不大于32M，否则可能不会带来好的性能提升。 reference picture5 在没有join group的情况下，表的关联查询是如何实现的：假如vehicles表和sales表需要做关联查询。 1、扫描Vehicles表，并将满足条件的行解压并发送到hash 连接 2、使用vehicles中获取的做连接的列创建hash列表 3、扫描sales表，过滤出符合条件的行 4、解压过滤得到的行，并发送至hash连接 5、使用vehicle表的ID值进行探测，找到匹配的行使用join group后的连接访问方式如下： 1、扫描vehicles表，将符合条件的以压缩的方式发送至hash 连接 2、对上步中压缩的结果中的不同值创建数组 3、扫描sales表 4、将匹配的行以压缩的方式发至hash 连接 5、对数组中压缩的值做全连接因此我们看到，没有使用join group的时候，最后在选择行的时候是扫描二维的hash表获得，而使用join group之后只需要扫描一个数组，这样就加快了查询效率。文章转自数据和云公众号，原文链接

2017-07-17

《从知识库到本体驱动应用》第3招企业架构 Enterprise Architecture——AI 如果只理解局部文档，就永远看不到企业全貌

手机厂老板问CIO：“海外订单交付老是延期，你打算改哪个系统？”如果只回答改CRM或改MES，这事基本就黄了。我是老李，最近在一家手机制造企业做架构梳理，发现真正的问题不是缺系统，而是战略到技术中间断了。今天借LTC这条线，把TOGAF怎么落地一次讲透。 ## 01、痛点这家手机厂的系统不算少。ERP、MES、CRM、PLM、WMS、SRM、TMS，常见的都上了，但业务部门还是天天催数据，IT部门天天救火，管理层看报表总觉得不对。典型的场景是这样的：销售说订单状态看不到，计划说物料数据不准，工厂说生产工单和销售订单对不上，财务说回款认领靠线下表格。每个部门都认为自己提过需求，每个系统都号称有接口，但问题仍然反复出现。更深层的问题是断裂。战略会上写着“提升海外订单交付及时率”，到了IT项目里变成“新增订单状态同步接口”。中间的业务能力、价值流、数据对象、应用边界，没有人完整说清楚。于是需求文档越写越厚，系统越建越多，架构图越画越复杂，但企业真正的问题没有被回答：一个战略目标，到底应该落到哪个业务流程、哪个数据对象、哪个应用、哪个技术平台？现在还要再加一个变量。当大模型开始进入企业，团队希望它帮忙分析变更影响、生成设计建议、辅助排障。如果只把需求文档丢给它，它只会把企业理解成一堆功能清单，看不见战略约束、业务责任、数据依赖和基础设施边界。这不是模型能力不够，而是输入本身缺乏结构。 ## 02、是什么 TOGAF在这件事上的价值，不是给你一套画图模板，而是逼着你建立一种连续映射。企业不是系统集合，而是战略目标、业务能力、价值流、数据对象、应用组合和技术平台形成的连续映射。这句话听起来抽象，放到手机制造企业就具体了。战略目标可以是一句“提升海外订单交付及时率”。业务能力是订单履约、全球供应链计划、交付物流。价值流是LTC，也就是从线索到回款的端到端过程。数据对象是客户、订单、物料、供应商、工厂、发货单、回款单。应用是CRM、ERP、MES、TMS。技术平台是云、API网关、微服务、容器、安全容灾。 TOGAF要做的是把这些层串成一条可以追溯的链。比如“提升海外订单交付及时率”这个目标，最终能追到“订单服务”的某个接口、某张订单状态表、某条云上的部署链路。反过来，任何一个技术变更，也能向上看到它会影响哪个业务能力，进而影响哪个战略指标。这跟传统信息化最大的区别在于：传统方式关注的是“系统有什么功能”，TOGAF关注的是“为什么会有这个功能、它服务谁、依赖什么、变化会影响谁”。 ## 03、为什么为什么不能只靠需求文档？因为需求文档大多记录的是结果，而不是根因。比如需求文档写“销售订单状态需要实时同步给销售团队”。这句话本身没错，但它是结果。它的根因是战略上要提升客户体验，落在业务能力上叫订单可视化，落在价值流上叫LTC的订单履行环节，落在数据对象上叫销售订单主数据，落在应用上叫CRM与ERP集成，落在技术上叫API调用与消息同步。如果只读“订单状态同步”，开发团队很可能直接在两个系统之间加一张同步表或一个接口。短期看问题解决了，长期看又多了一条没人说得清的集成链路。等到再改一个字段、升一个版本、迁一朵云，所有人又开始重新排查。 TOGAF的穿透关系解决的就是这个问题。它让每个需求都不是孤立的，而是被放回一条链上。KPI“交付及时率”下降时，可以从能力地图看到影响交付的订单承诺、物料齐套、物流执行几个能力，再沿着应用与数据追到具体接口和表。会议上的扯皮会变少，因为责任、依赖和影响都有据可查。对大模型来说更是如此。模型不缺少推理能力，缺少的是企业内部的确定性结构。如果你给它的是战略地图、能力地图、价值流、数据对象、应用接口和部署图之间的关联，它才能判断一个变更到底会波及多广。 ## 04、架构这个项目的整体架构可以分成六层：战略层、业务层、数据层、应用层、技术层、实施层。战略层的产物是PEST、战略屋、战略地图和KPI树。PEST回答外部环境为什么变，战略屋回答我们往哪里走，战略地图回答内部流程怎么支撑，KPI回答怎么算赢。业务层的产物是能力地图、价值流和RACI。能力地图回答企业能做什么，价值流回答这些能力怎么连成端到端过程，RACI回答谁负责、谁执行、谁被咨询、谁被告知。数据层的产物是主题域、数据对象、主数据和数据血缘。主题域回答数据的大类怎么分，数据对象回答业务事实怎么存，主数据回答哪些实体需要全局一致，数据血缘回答数据从哪里来、到哪里去。应用层的产物是应用组合、应用功能、API和微服务边界。应用组合回答有什么系统，应用功能回答系统提供什么能力，API回答能力怎么对外暴露，微服务边界回答哪些功能应该被拆开、哪些应该合并。技术层的产物是云平台、容器、安全容灾和部署架构。云平台回答跑在哪里，容器回答应用怎么封装，安全容灾回答业务连续性怎么保证。实施层的产物是迁移波次、里程碑和风险清单。迁移波次回答先迁什么、后迁什么，里程碑回答每个阶段怎么验收，风险清单回答可能在哪里翻车。如果用一条链表示，可以写成： PEST → 战略屋 → 战略地图 → KPI → 能力地图 → 价值流 → RACI → 主题域 → 主数据 → 应用 → API → 微服务 → 云平台 → 安全容灾 → 迁移波次。这条链不是流程图，不是做完一步再走下一步，而是一张映射图。每一层都同时存在，只是从不同视角看同一家企业。 ## 05、实战具体到这家手机厂，项目以LTC为主线，目标只有一个：把战略上讲的“海外订单交付及时率从82%提升到92%”真正落到系统、数据、接口和云资源上。战略层先做PEST。海外市场的合规要求提高，汇率波动变大，本地化交付压力增加。战略屋据此定下三大支柱：海外增长、交付体验、柔性供应。战略地图进一步落到内部流程：提升订单承诺准确率、提升物料齐套率、压缩清关与物流周期。KPI拆成OTD、订单承诺准确率、物料齐套率、清关周期四个数值。业务层围绕LTC展开。能力地图识别出线索管理、商机评审、订单承诺、订单履行、物流交付、回款对账等核心能力。价值流把这些能力串成一条从线索到回款的完整过程。RACI明确销售、计划、采购、生产、物流、财务的责权。比如“订单承诺”这个能力，计划主导，销售执行，IT支撑；如果承诺规则变更，受影响的是销售和计划两个角色，而不是所有人。数据层先划分主题域：客户、订单、物料、供应商、工厂、财务。主数据确定客户主数据、物料主数据、供应商主数据。这里最典型的坑是物料主数据，手机行业物料既有整机SKU，也有主板、屏幕、摄像头等关键器件，还有不同区域版本。如果物料主数据不统一，订单、生产、采购、物流各系统对同一个物料的理解就会不同。以销售订单为例，它的数据对象关联客户、物料、工厂和交付地址。生产工单关联销售订单和物料清单。发货单关联销售订单和客户。回款单关联发货单和客户。这样一层的关联关系建好后，订单交付问题才能被快速定位。应用层把现有系统重新归类。CRM承接线索和商机，ERP承接订单和财务，MES承接生产过程，TMS承接物流执行，SRM承接供应商协同。API层面划分订单中心、物料中心、物流中心、结算中心。订单中心提供订单创建、订单查询、订单状态变更；物料中心提供库存查询、库存预留；物流中心提供轨迹查询、签收回传；结算中心提供回款登记、对账。微服务边界也顺势清晰了：订单服务、库存服务、交付服务、结算服务各自独立。订单服务不直接写库存表，而是调用库存服务的预留接口；交付服务不直接改订单状态，而是通过订单服务发布状态事件。这样就不容易再造出那种谁也看不懂的网状集成。技术层采用混合云。订单应用和物流应用容器化后部署在公有云，核心ERP和MES保留在私有云或本地数据中心，通过专线和VPN打通。API网关统一做鉴权、限流和日志。安全容灾上，主数据中心与同城灾备之间做数据复制，异地做关键数据备份，核心交易数据多副本保留。实施层拆成三个迁移波次。第一波迁移CRM和订单中心，验证订单主数据准确率和接口时延；第二波迁移库存中心和物流中心，验证库存预留和轨迹查询；第三波迁移财务结算和主数据治理，验证回款对账和客户、物料主数据一致性。每一波都有明确验收指标，比如接口时延低于300毫秒、OTD数据准确率达到99%。最后，团队把这些关系做成交互式架构原型。在原型上点击KPI“交付及时率”，能看到关联的能力、价值流、应用、API、数据表和云资源。点击“新增海外订单信用审核节点”，能显示受影响的能力是订单承诺，受影响的应用是CRM和ERP，受影响的数据对象是销售订单和信用记录，受影响的迁移波次可能是第一波。这个原型不是画出来看的，而是拿来查和问的。 ## 06、洞见这次落地最大的体会是：企业架构不是文档，而是一种可追问的模型。很多企业做TOGAF，最后做成了文件柜。PEST一张图，战略屋一张图，能力地图一张图，应用架构一张图，数据架构一张图。图与图之间没有连线，看上很美，实际上谁也不会用。真正有价值的是穿透关系，而不是图的数量。颗粒度也很关键。太粗，无法指导实施，比如只写一句“建设柔性供应链”；太细，又没人能维护，比如把每个字段的来源和去向都画出来。比较好的方式是以价值流为主线，以业务能力为桥梁，以数据对象为证据，以应用和API为落点。当大模型要理解一家企业时，它需要的不只是需求文档。需求文档只回答“要做什么”，架构地图回答“为什么做、属于哪个能力、依赖什么数据、落在哪个应用、跑在什么平台、迁移时要注意什么”。前者是片段，后者是上下文。 ## 07、行动如果你所在的企业也面临类似的断裂，不要一上来就搞全面TOGAF，也不要急着买一堆工具。先从一条端到端价值流开始，比如LTC。第一步，选一条价值流，把KPI、业务能力、RACI、主题域、主数据、应用、API、云资源和迁移波次串成一张表。表里每一行不是独立名词，而是连成一条链。第二步，把这张表做成可交互的原型。不要只画静态图。让团队能点击问题“订单状态为什么不同步”，顺着链找到API、数据源和责任人。原型不需要复杂，能回答追问即可。第三步，用一个变更场景验证。比如增加一个海外订单信用审核节点，看这张图能不能回答影响哪些能力、哪些应用、哪些数据、哪些迁移波次。如果回答不了，说明映射还不完整。最后回到那个问题：当AI要理解一家企业时，它应该只读取需求文档，还是应该同时理解战略、业务、数据、应用和技术之间的关系？这不是一个技术选择题，而是企业未来数字化深度的分水岭。 ## 08、小结手机制造企业的复杂性，不在单个系统的功能多少，而在战略到技术之间能否保持连续映射。这篇文章以LTC为主线，用TOGAF把PEST、战略屋、战略地图、KPI、能力地图、价值流、RACI、主题域、主数据、应用、API、微服务、云平台、安全容灾和迁移波次串成一条可追溯的链。企业不是系统集合，而是关系的组合。架构的价值不在图多，而在可追溯、可追问、可执行。哪个团队先建立这套穿透关系，哪个团队就能在业务变化和大模型应用上更快一步。 ## 09、链接与概念说明 TOGAF：企业架构方法，本文强调其分层映射和穿透追溯能力。 LTC：线索到回款，销售交付端到端价值流。 PEST：从政治、经济、社会、技术四个维度分析外部环境。战略屋：把战略意图、目标、路径和支撑分层表达的结构图。战略地图：将战略目标转化为内部流程、客户、财务、学习成长四个层面的因果关系。 KPI：关键绩效指标。能力地图：描述企业为完成战略目标所需的业务能力。价值流：端到端创造价值的活动序列，如LTC。 RACI：责任分配矩阵，明确主导、执行、咨询、被告知四类角色。主题域：企业数据的高层分类，如客户、订单、物料。主数据：跨系统共享的核心数据，如客户、物料、供应商。 API：应用之间暴露能力的接口。微服务：按业务边界拆分的小型服务。云平台：承载应用和数据的基础设施。安全容灾：保障业务连续性的技术措施。迁移波次：分批迁移系统与数据的实施节奏。以上概念不必一次性全部引入，按价值流验证需要逐步落地即可。

2026-09-01