当前位置：首页 > news >正文

自己做的公司网站百度搜不到中国城乡和住房建设部网站

news 2025/10/29 23:56:04

自己做的公司网站百度搜不到,中国城乡和住房建设部网站,软件商城官方下载,美食网站源码目录一、可见可观测 1.1 概述 1.2 服务可见性 1.2.1 概述 1.2.2 服务描述 1.2.3 服务所有权 1.2.4 服务对外接口 1.2.5 服务SLA 1.2.6 服务的上下游拓扑 1.2.7 服务变更 1.2.8 服务接入和资源配额管理 1.2.9 服务线上部署和线下测试环境信息 1.3 变更可见性 1.4 … 目录一、可见可观测 1.1 概述 1.2 服务可见性 1.2.1 概述 1.2.2 服务描述 1.2.3 服务所有权 1.2.4 服务对外接口 1.2.5 服务SLA 1.2.6 服务的上下游拓扑 1.2.7 服务变更 1.2.8 服务接入和资源配额管理 1.2.9 服务线上部署和线下测试环境信息 1.3 变更可见性 1.4 可观测性 1.4.1 概述 1.4.2 Logging系统 1.4.3 Metric系统 1.4.3.1 概述 1.4.3.2 日志监控系统的缺点 1.4.3.2.1 规则简单 1.4.3.2.2 业务量大时影响性能 1.4.3.2.3 可维护性差 1.4.3.3 总结 1.4.4 Tracing系统 1.4.4.1 概述 1.4.4.2 分布式跟踪系统 1.4.4.2.1 分布式跟踪系统出现的业务背景 1.4.4.2.2 分布式跟踪系统起源与发展 1.4.4.2.3 分布式跟踪系统的原理 1.4.4.2.4 分布式跟踪系统需要具备的优点 1.4.4.2.4.1 低侵入接入 1.4.4.2.4.2 低开销 1.4.4.2.4.3 高稳定 1.4.5 总结二、量化分析体系 2.1 概述 2.2 稳定性风险度量 2.3 基于多维度监控的故障定位 2.4 风险分析一、可见可观测 1.1 概述可见可观测是服务治理反馈机制的第一步只有获取到足够多有价值的数据才能对服务的运行状态进行分析和控制。 1.2 服务可见性 1.2.1 概述服务元数据平台负责维护服务相关的元数据信息主要包括服务层面、接口层面、拓扑层面这几个维度的元数据信息通过服务元数据平台可以对系统提供全方位的可见性。服务层面服务元数据平台汇聚了当前所有的服务列表默认按照服务功能进行分类业务需要某种功能的服务时就可以直接到服务商城浏览和查询做到服务信息的透明化减少重复建设。为了增强服务查询的灵活性可以支持多种服务查询方式比如按照服务所属部门查询、按照服务属性查询等服务基本信息平台化等。服务基本信息如下。 1.2.2 服务描述简要描述服务提供的基本能力服务的适用场景等供潜在服务使用者参考必要时可以加上服务的详细描述信息wiki以及服务对应的邮件组和沟通群。 1.2.3 服务所有权服务当前所属部门、服务当前的owner等。 1.2.4 服务对外接口服务接口定义使用说明和注意事项等。 1.2.5 服务SLA 服务对外的SLA承诺。 1.2.6 服务的上下游拓扑服务商城中维护了每个服务的上下游依赖基于上下游依赖不仅可以查询上下游服务的使用方式和使用情况同时也可以进行服务重大变更时的上下游服务通知。 1.2.7 服务变更服务商城中维护服务每个重要变更的变更日志重要变更时会通过相应机制知会上下游依赖上下游会评估是否需要适配升级等这样服务使用者可以从变更历史中了解到服务的整个发展脉络。 1.2.8 服务接入和资源配额管理服务如何接入资源配额如何申请等。 1.2.9 服务线上部署和线下测试环境信息描述了服务线上和线下的部署信息使用者直接基于平台给定的环境使用。服务元数据平台的作用是将服务基本信息平台化同时可以将服务接入、服务客服等日常工作从线下转移到线上减少线下的人力成本开销。因此服务元数据平台的评价标准是微服务接入和运营时线下沟通的比重。 1.3 变更可见性变更是引发系统故障的主要因素通过对各个维度的变更进行系统的梳理和记录不仅方便出现故障时的追溯和定位后续还可以基于完善的变更事件库对这些变更的原因、质量以及影响进行全面的审计和分析从中找到规律性的东西建立相应的改进反馈闭环。服务变更是变更的最重要来源常见的服务变更方式有应用变更、配置变更、数据变更以及预案变更等。对于微服务架构来说除了关注当前服务的变更之外还需要关注上下游依赖服务的变更以及部署层面关联服务的变更比如和当前服务混部在同一台物理机上的其他服务变更。除了服务变更还需要对服务周边的各个环境变更进行记录比如网络变更、机器变更、机房变更、交换机变更这些变更都可能对服务的正常运行产生影响。 1.4 可观测性 1.4.1 概述微服务架构下各个微服务采用分布式部署并且通过网络进行分布式通信随着微服务个数和集群规模的扩大系统中会产生各种形式的故障并且很多故障是无法事先预测的因此需要有完善的平台和工具体系能够对微服务的运行状态进行全方位多维度的监控使得我们可以随时掌握微服务当前的运行状态并且针对运行状态不正常的场景进行及时处理。可观测性就是用于上述微服务状态监控的工具集合具体分为Logging日志系统、Metrics度量系统和Tracing分布式跟踪系统3个层次三者的关系图如下图所示 1.4.2 Logging系统日志用于对系统中离散的事件进行记录比如服务的调试信息和错误信息日志是系统监控的基石也是服务状态监控和问题诊断的第一个抓手通过日志可以大体判断系统的运行状态是否正常。日志是最常见、最通用的监控手段但服务的日志监控和告警一般都需要人工添加不仅效率低也很容易遗漏。同时不同服务的日志格式和日志信息可能都会有差异不太方便进行标准化不仅日志收集、处理和展示比较麻烦有太多个性化的需求而且每个服务的日志都不统一基于日志的全系统问题定位也非常麻烦。 1.4.3 Metric系统 1.4.3.1 概述为了提高日志和监控的标准化引入了Metric的概念Metric就是将日志中可以聚合的部分通过标准化的协议进行处理Metric定义一套完善的日志收集、传输和处理标准通过Metric可以实现日志和监控的标准化同时基于Metric的日志聚合特性聚合后的日志会小很多减少日志系统的成本开销。监控标准化是在业务中埋点主动上报标准业务指标来满足业务监控需求的解决方案。期望在业务完成标准上报之后自动给业务提供调用关系拓扑、自动错误率监控、自动服务可用性计算、服务性能评估等高级功能。 1.4.3.2 日志监控系统的缺点业务服务一般习惯于使用日志监控的方式监控系统对日志的监控也容易实现但日志监控有如下几个缺点。 1.4.3.2.1 规则简单日志监控采集只能适用于简单规则比如流量采集、接口平均耗时等在耗时上采用平均耗时在分析业务性能时缺少精细粒度的分位耗时信息比较难科学反应模块性能。 1.4.3.2.2 业务量大时影响性能日志监控分析在业务流量大的情况下在线消耗性能比较多。 1.4.3.2.3 可维护性差日志监控采用配置分析的模式让监控系统和日志格式有依赖如果修改代码的时候不小心调整了日志格式忘记调整对应监控正则会导致日志监控出错。 1.4.3.3 总结相比之下标准化监控主动上报监控指标可以自动绘出调用链为服务可用性提供衡量指标支持复杂的统计功能可以定制业务相关的复杂策略。为了实现监控标准化针对监控项的收集和上报需要制定一个规范如果各个业务或者一个业务的各个接口都按照上述的规范那么可以在监控自动化上做到更高程度避免人工配置。举个例子如果一个业务的各个接口都有错误率且各个接口的错误率不能超过30%那么只需要配置错误率≥30%就报警则新增一个接口自动添加报警可以实现报警自动化。监控项规范可以规定所有上报的监控项均需要关注QPS、耗时和错误率这几个服务基础监控指标。标准化项采集实现起来也比较简单可以借鉴开源系统statsd的设计思想在业务代码中引入监控标准化SDK。SDK负责实现监控项埋点和统计功能以及服务间RPC调用质量等业务指标SDK通过UDP协议上报业务监控指标项到本机的Agent本机Agent以一定的周期如10s为周期聚合业务指标并将聚合结果发送到监控平台。 1.4.4 Tracing系统 1.4.4.1 概述 Tracing用于记录请求级别的信息它会跟踪请求整个链路的执行过程和各阶段耗时信息基于Tracing可以定位请求性能问题和跨服务交互相关的问题。 1.4.4.2 分布式跟踪系统 1.4.4.2.1 分布式跟踪系统出现的业务背景大型互联网公司的微服务架构下一个业务可能会有上百个微服务组成一次请求由几十次服务调用共同完成。这种架构下就会出现很多跨服务的问题比如请求处理为什么突然变慢问题具体出在那个环节业务故障的排查是哪个流程中出错等通过分布式跟踪系统可以建立一个以请求为中心的全局视图查看请求处理过程中各个阶段的具体状态和处理情况。 1.4.4.2.2 分布式跟踪系统起源与发展 2010年Google发表了一篇名为《Dappera Large-ScaleDistributed Systems Tracing Infrastructure》的论文介绍了Google生产环境中大规模使用的分布式跟踪系统Dapper的设计原理和使用经验Dapper掀开了分布式跟踪系统的序幕。之后Twitter根据这篇论文开发了自己的分布式跟踪系统Zipkin并将其开源。现在不少国内外的大型互联网公司也都有自己的分布式跟踪系统比如Uber的Jaeger、阿里的鹰眼、京东的Hydra、微博的Watchman等这些分布式跟踪系统的原理基本都差不多一般分为数据采集、数据传输、数据处理和数据展示4个方面下面以Dapper为例讲述分布式跟踪系统的大体实现。 1.4.4.2.3 分布式跟踪系统的原理首先看下分布式跟踪相关的几个重要概念TraceID用于对请求进行唯一标识一般是请求进入链路处理入口时生成比如在接入层生成此后一直在请求处理的整个链路中一直携带和传递不再修改。TraceID是分布式跟踪系统中最重要的概念通过TraceID串联请求的各个阶段同时也通过TraceID查询请求的整个处理链。 Span ID用于标识请求在一个模块内的处理过程理论上讲SpanID只需要做到同一个TraceID下唯一即可不需要全局唯一。为了通过服务调用关系实现请求调用链信息的组织调用下游服务时需要将自身的Span ID和TraceID传递给下游服务下游服务会将上游服务传递过来的Span ID作为自己的父Span ID并通过一定的方式生成自身的Span ID然后使用TraceID、父Span ID和Span ID生成标准化的Trace日志分布式跟踪系统收集各个服务的Trace日志然后通过TraceID完成一个请求对应Trace日志的收集通过父Span ID和Span ID完成请求跟踪树的建立。 Annotation用于给跟踪信息添加相应的注释这个注释信息是带时间戳的Annotation可以添加任意请求相关的信息通过Annotation方便进行一些业务相关的问题定位。对于分布式跟踪系统来说TraceID和Span ID的正确生成是一个非常重要的前提不同分布式跟踪系统的ID生成规则不一样对于TraceID来说必要条件是全局唯一同时为了方便根据TraceID进行问题定位和追查TraceID生成时可以加入一些请求相关的基本信息。对于Span ID的生成必要的约束条件是保证同一个请求下的不同节点对应的Span ID唯一即可。不同的分布式跟踪系统生成Span ID的方式也不尽相同比如阿里的鹰眼系统巧妙用Span ID来体现调用层次关系例如00.10.20.1.1等对于请求的根节点来说使用一个特殊的标识来标识当前节点是根节点没有上游信息。 1.4.4.2.4 分布式跟踪系统需要具备的优点 1.4.4.2.4.1 低侵入接入低侵入接入不仅是分布式跟踪也是所有服务治理相关特性的共同需求。服务治理特性接入最好能做到对业务透明这样接入的过程中不会有特别大的阻力如果业务需要花费比较大的改造成本才能完成接入业务接入的意愿就不会那么强烈。为了实现透明低侵入接入一般可以将分布式跟踪特性下沉到服务框架或者Service Mesh层面尤其是Service Mesh可以真正做到让分布式跟踪特性的修改对业务服务完全透明业务服务零改动。 1.4.4.2.4.2 低开销为了减少对业务服务正常运行的影响分布式跟踪需要做到尽可能轻量尤其是一些性能特别敏感的业务需要随时调整Trace日志采集频率甚至需要Trace日志采集开关。为了减少对业务服务正常运行的影响分布式跟踪需要做到尽可能轻量尤其是一些性能特别敏感的业务需要随时调整Trace日志采集频率甚至需要Trace日志采集开关。 1.4.4.2.4.3 高稳定分布式跟踪作为基础服务治理组件如果没有足够的稳定性保障会给业务服务带来非常严重的后果因此分布式跟踪系统设计和实现过程中的各个环节都要考虑稳定性因素尽可能简化设置。对于Trace日志输出来说不要有太复杂的处理逻辑同时日志收集代理尽可能轻量部署减少不必要的依赖。当前国内外主流互联网公司基本上都有自己的分布式跟踪系统但这些系统实现各异并且相互不兼容无法实现跨业务、跨公司的全链路跟踪制约了全链路跟踪的进一步发展为了解决不同分布式跟踪系统API不兼容的问题诞生了OpenTracing规范OpenTracing是一个轻量级的标准化层希望通过OpenTracing实现分布式跟踪的兼容互通和标准化。当前OpenTracing已进入CNCF成为云原生基础设施的一部分OpenTracing通过提供平台无关、语言无关的API使得开发人员能够方便地替换追踪系统目标是为全球的分布式追踪提供统一的概念和分布式跟踪标准。 OpenTracing数据模型中重点定义了两个相关的概念Span Tag和Log Field其中Span Tag定义一系列作用于整个Span过程的Tag每个Span的log操作都具有一个特定的时间戳这个时间戳必须在Span的开始时间和结束时间之间以及一个或多个fieldLog Field定义了一系列标准化的Log Field字段通过Span Tag和Log Field实现了分布式跟踪输出的标准化。 OpenTracing规范还在不断完善过程中当前Jaeger和Zipkin均实现了对OpenTracing的支持。 1.4.5 总结 Logging、Metric和Tracing这3个系统关注的侧重点有所不同。Logging系统对服务的运行状态和事件进行记录比如调试日志、错误日志等日志记录一般会比较全有时出于性能考虑可能需要在不同场景下打开相应的日志开关这些日志会作为问题追查和定位的依据。Metric系统侧重事件聚合相比日志来说Metric关注的对象相对小一些比如服务QPS、成功率、耗时等聚焦核心指标基于Metric可以方便实现服务核心指标的监控告警自动化。Tracing关注请求级别的处理。使用过程中一般先关注日志监控是否有问题如果有问题通过Metric查看具体的服务和指标异常最后通过Tracing进行全链路排查。一般通过无处不在的Metric监控发现大面上的异常或隐患如机器cpu idle过低、服务崩溃退出等再通过Tracing系统查看异常机器或实例上的轨迹确认异常由哪个环节引入造成了多大损失例如个别机器CPU idle低处理慢因为有上游重试未必会造成损失如果问题由业务逻辑导致此时基本能找到根因否则再通过Metric系统确定运行环境类根因如查看异常机器或实例上的QPS、CPU idle率、进程CPU使用率的秒级曲线最终判定cpuilde低是由QPS增加导致还是其他进程CPU使用率增加导致。一般来说对于大故障直接关联分析各种指标就能定位出问题对于零星故障业务逻辑故障上下游耦合类故障如调度要通过跟踪才能分析清楚。二、量化分析体系 2.1 概述量化分析体系是基于数据对系统进行量化、定位和分析然后产生相应的治理措施指导接下来的线上治理和线下治理接下来从度量、定位和风险分析这几个维度对量化分析体系进行展开讨论。 2.2 稳定性风险度量稳定性工作包含的内容很多在稳定性建设过程中经常会遇到这样一个问题——服务当前的稳定性现状不太好衡量和判断。比如服务变更一直以来是影响服务稳定性的重要因素由于没有明确的衡量标准和规范很难说清楚服务变更做到什么程度才算是符合稳定性要求的变更这样会导致执行服务变更的同学很难发现自己平常工作的不足同时团队的管理者层面看不到自己团队变更风险的全貌和严重程度。服务变更只是稳定性建设的一个缩影稳定性建设的很多维度和服务变更类似。为了掌握稳定性建设的真实情况同时引导和规范业务同学在稳定性建设时的做法针对稳定性的一些重要环节需要制订一定的度量标准对业务同学日常的稳定性建设进行度量明确告诉大家当前的稳定性工作处于什么水准具体哪些地方需要改进。以服务变更为例流程规范规定高峰期不能上线平台可以强制规定不能在这个时间上线但一定会有紧急的需求需要在高峰期操作所以平台还必须放开这个口子。这类操作带来的风险也是确确实实存在的它不应该被经常执行比如灰度检查通常暂停的时间越长越有可能发现问题但平台只能约束至少有暂停或暂停一个固定时间更长的暂停时间则由执行者把握。诸如这些问题可以结合变更规范制定一个量化标准——更信用分标准。比如变更信用分标准可以规定暂停时间越长分数越高高峰期如有操作则需要扣分同时不同优先级的模块采用不同的标准最高优先级的模块有强制双重校验的要求需要两个人校验后才能在平台上线如果没有在平台执行这个要求也需要扣分。按照变更信用分标准对每周的上线单进行系统分析并按团队汇总、量化和排名让大家能从全局的角度看到问题的总体情况和各自的严重程度并能够从上往下索引到各个团队具体的变更单、变更人和变更参数甚至直到具体的变更模块配置界面以此促进各个团队有针对性地发现变更风险并清晰地知道如何进行完善。定期将每个团队本周的变更评分情况以及存在变更风险的变更操作单发送到对应团队的负责人与变更风险单的实际操作者方便业务人员了解当前的变更风险并及时针对性地进行改进。针对稳定性建设的其他方面我们也可以按照上述变更信用分的思路建立相应的度量标准。比如监控告警针对基础监控是否有遗漏配置、上下游依赖健康是否完备、告警策略是否符合要求等情况可以推出监控健康分量化服务监控告警的完备情况引导用户进行监控告警的完善工作。比如预案建设方面可以推出预案健康分量化一个服务的预案建设情况涉及降级限流等预案是否完备预案执行是否符合灰度要求预案是否可以回滚等。对于稳定性度量来说主要是确定具体的度量指标以及每个度量指标的标准评分。其实具体评分并不是那么重要关键是大家对度量标准能够达成一致能够对稳定性日常工作有实际的量化指导效果。 2.3 基于多维度监控的故障定位线上服务出现问题时当有足够多的监控信息时才能直观地定位问题。但随着业务规模变大微服务的个数越来越多链路、拓扑、网络越来越复杂相应的监控事件越来越多。当出现故障可能瞬间出现大量的报警信息从众多告警中快速找到故障原因确定相应的止损预案是一个非常重要且有挑战性的事情。出现故障时首先需要确定故障的影响面可以基于场景和分布式跟踪拓扑将业务组织成一个全局的“灭火图”灭火图中包括所有核心服务的可用性指标比如错误率、QPS、耗时等出现故障时先从灭火图中看出故障影响的业务和服务接下来确定故障定位的范围。为了从纷繁复杂的众多事件中定位具体的原因可以将各维度的监控报警、各种变更事件以事件的方式按照时间轴整合成一个时间线有了事件时间线我们就可以将关注焦点放到故障时间前一段时间内的监控告警事件以及变更事件上从而根据具体的事件类型确定相应的预案和止损措施。 2.4 风险分析基于线上实时的可观测数据以及研发全流程的变更和操作数据我们可以得出很多维度的报表和趋势数据。这些维度可以涵盖服务治理的各个环节比如链路SLA、超时重试、容量管理、强弱依赖关系等这些数据可以作为接下来分析的基础。同时根据之前的风险分析以及一些静态的服务元数据信息会形成一个和当前实时治理数据对应的历史基准库将当前数据和历史基准库进行比较从中找到趋势和规律进而发现潜在的风险。实时治理数据分析后一些有价值的东西可以沉淀到历史基准库作为后续风险分析的基础进而形成一个风险分析的闭环机制。在基于风险分析的在线上治理和线下治理中会结合具体的场景和实例进行全面的剖析。好了本次内容就分享到这欢迎大家关注《微服务架构》专栏后续会继续输出相关内容文章。如果有帮助到大家欢迎大家点赞关注收藏有疑问也欢迎大家评论留言
文章转载自：
http://www.morning.wqfrd.cn.gov.cn.wqfrd.cn
http://www.morning.wbhzr.cn.gov.cn.wbhzr.cn
http://www.morning.tdxnz.cn.gov.cn.tdxnz.cn
http://www.morning.rdkgw.cn.gov.cn.rdkgw.cn
http://www.morning.rkmsm.cn.gov.cn.rkmsm.cn
http://www.morning.mkhwx.cn.gov.cn.mkhwx.cn
http://www.morning.kfcfq.cn.gov.cn.kfcfq.cn
http://www.morning.hwcgg.cn.gov.cn.hwcgg.cn
http://www.morning.rkck.cn.gov.cn.rkck.cn
http://www.morning.cwwts.cn.gov.cn.cwwts.cn
http://www.morning.ppdr.cn.gov.cn.ppdr.cn
http://www.morning.gcfg.cn.gov.cn.gcfg.cn
http://www.morning.mqfw.cn.gov.cn.mqfw.cn
http://www.morning.tlbhq.cn.gov.cn.tlbhq.cn
http://www.morning.llqky.cn.gov.cn.llqky.cn
http://www.morning.kpypy.cn.gov.cn.kpypy.cn
http://www.morning.cmdfh.cn.gov.cn.cmdfh.cn
http://www.morning.wptrm.cn.gov.cn.wptrm.cn
http://www.morning.jlschmy.com.gov.cn.jlschmy.com
http://www.morning.tdmgs.cn.gov.cn.tdmgs.cn
http://www.morning.lzwfg.cn.gov.cn.lzwfg.cn
http://www.morning.crkmm.cn.gov.cn.crkmm.cn
http://www.morning.jcwrb.cn.gov.cn.jcwrb.cn
http://www.morning.bxdlrcz.cn.gov.cn.bxdlrcz.cn
http://www.morning.bpmtz.cn.gov.cn.bpmtz.cn
http://www.morning.tpbhf.cn.gov.cn.tpbhf.cn
http://www.morning.brld.cn.gov.cn.brld.cn
http://www.morning.nfzw.cn.gov.cn.nfzw.cn
http://www.morning.cqwb25.cn.gov.cn.cqwb25.cn
http://www.morning.tpbhf.cn.gov.cn.tpbhf.cn
http://www.morning.nwjd.cn.gov.cn.nwjd.cn
http://www.morning.vuref.cn.gov.cn.vuref.cn
http://www.morning.mrxqd.cn.gov.cn.mrxqd.cn
http://www.morning.kgfsz.cn.gov.cn.kgfsz.cn
http://www.morning.rqwwm.cn.gov.cn.rqwwm.cn
http://www.morning.lhqw.cn.gov.cn.lhqw.cn
http://www.morning.lpnb.cn.gov.cn.lpnb.cn
http://www.morning.cplym.cn.gov.cn.cplym.cn
http://www.morning.snbq.cn.gov.cn.snbq.cn
http://www.morning.kjawz.cn.gov.cn.kjawz.cn
http://www.morning.fmqng.cn.gov.cn.fmqng.cn
http://www.morning.ccdyc.cn.gov.cn.ccdyc.cn
http://www.morning.tgpgx.cn.gov.cn.tgpgx.cn
http://www.morning.mnkhk.cn.gov.cn.mnkhk.cn
http://www.morning.tgtwy.cn.gov.cn.tgtwy.cn
http://www.morning.clqpj.cn.gov.cn.clqpj.cn
http://www.morning.xxrgt.cn.gov.cn.xxrgt.cn
http://www.morning.nggbf.cn.gov.cn.nggbf.cn
http://www.morning.qgkcs.cn.gov.cn.qgkcs.cn
http://www.morning.wqrk.cn.gov.cn.wqrk.cn
http://www.morning.yjtnc.cn.gov.cn.yjtnc.cn
http://www.morning.smyxl.cn.gov.cn.smyxl.cn
http://www.morning.wsnbg.cn.gov.cn.wsnbg.cn
http://www.morning.fhrgk.cn.gov.cn.fhrgk.cn
http://www.morning.sphft.cn.gov.cn.sphft.cn
http://www.morning.djlxz.cn.gov.cn.djlxz.cn
http://www.morning.mtbsd.cn.gov.cn.mtbsd.cn
http://www.morning.aa1585.com.gov.cn.aa1585.com
http://www.morning.mtktn.cn.gov.cn.mtktn.cn
http://www.morning.ggtkk.cn.gov.cn.ggtkk.cn
http://www.morning.hsklc.cn.gov.cn.hsklc.cn
http://www.morning.fslxc.cn.gov.cn.fslxc.cn
http://www.morning.sypzg.cn.gov.cn.sypzg.cn
http://www.morning.qfplp.cn.gov.cn.qfplp.cn
http://www.morning.drytb.cn.gov.cn.drytb.cn
http://www.morning.kcypc.cn.gov.cn.kcypc.cn
http://www.morning.nhdmh.cn.gov.cn.nhdmh.cn
http://www.morning.tqgx.cn.gov.cn.tqgx.cn
http://www.morning.cdygl.com.gov.cn.cdygl.com
http://www.morning.hsflq.cn.gov.cn.hsflq.cn
http://www.morning.hwcgg.cn.gov.cn.hwcgg.cn
http://www.morning.ykmg.cn.gov.cn.ykmg.cn
http://www.morning.bpmfz.cn.gov.cn.bpmfz.cn
http://www.morning.cfybl.cn.gov.cn.cfybl.cn
http://www.morning.tznlz.cn.gov.cn.tznlz.cn
http://www.morning.jfbbq.cn.gov.cn.jfbbq.cn
http://www.morning.ltspm.cn.gov.cn.ltspm.cn
http://www.morning.iuibhkd.cn.gov.cn.iuibhkd.cn
http://www.morning.rqrxh.cn.gov.cn.rqrxh.cn
http://www.morning.lksgz.cn.gov.cn.lksgz.cn

查看全文

http://www.tj-hxxt.cn/news/260838.html