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

规划网站建设的总体目标wordpress不能访问

news 2025/11/4 14:45:19

规划网站建设的总体目标,wordpress不能访问,微信开发者平台api,深圳南山区住房和建设局网站官网DevOps实践指南 Part 3 第一步 #xff1a;流动的技术实践11. 应用和实践持续集成11.1 小批量开发与大批量合并11.2 应用基于主干的开发实践11.3 小结 12. 自动化和低风险发布12.1 自动化部署流程12.1.1 应用自动化的自助式部署12.1.2 在部署流水线中集成代码部署 12.2 将部署… DevOps实践指南 Part 3 第一步流动的技术实践11. 应用和实践持续集成11.1 小批量开发与大批量合并11.2 应用基于主干的开发实践11.3 小结 12. 自动化和低风险发布12.1 自动化部署流程12.1.1 应用自动化的自助式部署12.1.2 在部署流水线中集成代码部署 12.2 将部署与发布解耦12.2.1 基于环境的发布模式12.2.2 基于应用的发布模式更安全 12.3 持续交付和持续部署实践的调查12.4 小结 13. 降低发布风险的架构13.1 能提高生产力、可测试性和安全性的架构13.2 架构原型单体架构与微服务13.3 安全地演进企业架构13.4 小结 - 接前文 - Part 3 第一步流动的技术实践第三部分的目标是创建必要的技术实践和架构从而使开发到运维的工作能够稳定地快速流动并确保不会造成生产环境的混乱或客户服务的中断。这意味着需要降低在生产环境中部署和发布变更的风险。这一点可以通过一套被称为持续交付的技术实践来实现。 11. 应用和实践持续集成分支在版本控制系统中的主要作用是让开发人员可以并行地工作在软件系统的各个组成部分同时避免开发人员提交的代码对主干trunk有时候也被称为 master 或 mainline的稳定性造成影响或者引入错误。然而开发人员在自己的分支上独自工作的时间越长就越难将变更并入主干。事实上当分支个数和每个分支上的变更数同时增加时合并难度会骤增。集成问题会导致大量的返工包括不得不通过手动合并解决变更冲突以及多名开发人员共同解决导致自动化测试或手动测试失败的合并问题。因为在传统的开发模式里代码集成工作通常发生在项目的末期所以在集成工作消耗过多时间时我们不得不为了按时发布而偷工减料。这会导致另一个恶性循环既然合并代码如此痛苦那么大家索性就减少合并次数而这会使未来的合并工作更加令人痛苦。持续集成旨在通过将合并融入日常工作来解决这个问题。 11.1 小批量开发与大批量合并每当提交到版本控制系统的代码变更导致部署流水线失败时我们就会群策群力地解决问题力求尽快将部署流水线恢复到绿色状态。然而如果开发人员长时间工作在自己的分支也称为“特性分支”上只是偶尔将代码合并到主干那么他们的每一次合并都会为主干引入大批量的变更这会造成严重的问题。尽管分支策略有很多种但是可以分为以下两类提高个人生产力所有人都在自己的分支上工作。每个人都独立地工作并且不能干扰其他人然而代码合并将是一场噩梦。协作将变得相当困难每个人都不得不谨小慎微地合并代码即便是完成系统里最小的部分也是如此提高团队生产力所有人都在同一个区域里工作。并没有分支只有一条很长、不可被中断的主干也没有规则因此代码的提交过程很简单。但是任何一次提交都有可能破坏整个项目同时导致项目中断。 Ward Cunningham 开发了世界上第一个维基系统也创造了“技术债务”一词。他在描述技术债务时说如果不能主动地重构代码库它就会慢慢地变得难以修改和维护新特性的增加速度也会因此而下降。持续集成和基于主干的开发实践其主要目的就是解决这些问题从而在提高个人生产力的基础之上提高团队生产力 11.2 应用基于主干的开发实践解决大批量合并问题的对策是应用持续集成和基于主干的开发实践让每个开发人员每天都至少向主干提交一次代码。这样做能够将代码提交量降低为开发团队每日的工作量。开发人员提交得越频繁每次的提交量就越小他们离理想的单件流状态也就越近。频繁地向主干提交代码意味着可以针对整个软件系统执行所有的自动化测试并且在应用或接口的某个部分出现问题时及时收到告警信息。由于合并问题能被及时发现因此也能被及时解决。我们甚至可以对部署流水线进行这样的配置拒绝接受任何使系统偏离可部署状态的提交例如代码变更或环境变更。这种方式被称为门控提交即部署流水线要确认所提交的变更能成功合并和正常构建并且在合并到主干之前就已经通过了所有的自动化测试。如果测试失败则开发人员将收到通知这样就可以在不影响价值流中的其他人的情况下自己解决问题。应用这些实践后我们再来修订“完成”的定义黑体文字为新增内容“在每个迭代周期结束时已经在类生产环境中集成和测试了可工作和可交付的代码这些代码通过一键式流程在主干上创建并已通过自动化测试。” 11.3 小结基于主干的开发方式可能是本书中最具争议的实践。许多工程师都认为它行不通他们更喜欢在自己的分支上工作不必与其他开发人员协作。然而Puppet Labs 的《2015 年 DevOps 现状报告》表明基于主干的开发方式能带来更高的生产力、更好的稳定性甚至更高的工作满意度和更低的职业倦怠率。虽然在开始时很难说服开发人员但是一旦他们认识到显著的优势就会彻底改变。持续集成实践为下一步实现低风险的自动化部署流程铺平了道路。 12. 自动化和低风险发布本章旨在通过减小生产环境部署的阻力使运维团队或开发团队能频繁、轻松地进行部署。我们通过扩展部署流水线来实现这一点。与仅将代码持续集成到类生产环境中不同我们将能够按需地即一键式发布或自动化地即在构建和测试成功以后直接进行自动化部署将已通过自动化测试和验证流程的任何构建版本发布到生产环境中。 12.1 自动化部署流程当完整记录目前的部署流程以后下一步的目标便是尽可能地简化和自动化手动步骤举例如下将代码打包成便于部署的格式创建预配置的虚拟机镜像或容器将中间件的部署和配置自动化将安装包或者文件复制到生产服务器重启服务器、应用或者服务基于模板生成配置文件通过执行自动化冒烟测试确保系统能正常运行并且配置正确运行各种测试程序将数据库迁移工作脚本化和自动化。大多数具有持续集成和测试功能的工具也有扩展部署流水线的能力。通常在生产验收测试执行完之后这些工具可以将验证过的构建版本发布到生产环境中这样的工具包括 Jenkins Build Pipeline插件、ThoughtWorks的GoCD和Snap CI、Microsoft Visual Studio Team Services以及Pivotal Concourse 部署流水线有如下需求用相同的方式处理所有环境的部署通过对所有环境例如开发环境、测试环境和生产环境采用相同的部署机制可以提高生产环境部署的成功率因为它已经在流水线中被成功地部署过很多次了。对部署执行冒烟测试在部署过程中应该测试依赖的所有系统例如数据库、消息总线和外部服务是否能正常访问并通过单次测试看看系统是否能正常工作。如果以上任何一个测试失败那么部署就是失败的。维持环境的一致性上述步骤创建了一步搭建环境的流程使得开发环境、测试环境和生产环境有了共同的搭建机制。必须持续保证这些环境的搭建方式是一致的 12.1.1 应用自动化的自助式部署为了更好地促进工作需要一个可以由开发人员或运维人员来执行的代码发布流程并且在理想情况下应该不需要任何手动操作或工作交接。这个流程的步骤如下。构建部署流水线必须基于版本控制系统构建可部署到任何环境包括生产环境的软件包。测试任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化测试套件。部署任何人都应该能够将这些软件包部署到具有访问权限的任何环境通过执行已提交到版本控制系统中的脚本来完成部署。以上实践有助于成功地执行部署谁来执行并不重要。 12.1.2 在部署流水线中集成代码部署如果代码部署过程是自动化的就能将其变成部署流水线的一部分。因此自动化部署必须具备如下能力保证在持续集成阶段构建的软件包可以部署到生产环境中使生产环境的就绪情况一目了然为能在生产环境中部署的任何代码建立一键式和自助式的发布机制自动记录审计和合规管理所需的相关内容包括在哪台机器上运行了命令运行了什么命令是谁授权的以及结果如何通过冒烟测试验证系统正常工作并且数据库连接字符串等配置正确为开发人员快速提供反馈使他们能够尽快了解部署结果例如部署是否成功应用是否能在生产环境中正常运行等等我们的目标是实现快速部署——不用等待数小时之后才知道部署是否成功也不用在修复代码上耗费数小时。运用 Docker 等容器技术可以在几秒钟或几分钟内完成很复杂的应用部署。通过构建上述能力能够实现一键式代码部署通过部署流水线将代码和环境变更一起安全、快速地发布到生产环境中 12.2 将部署与发布解耦在实践中人们通常交替使用“部署”和“发布”这两个词。然而它们其实是不同的动作并且有着截然不同的目标。部署是指在特定的环境中安装指定版本的软件例如将代码部署到集成测试环境中或生产环境中。具体地说部署可能与某个特性的发布相关也可能无关。发布是指把一个特性或者一组特性提供给所有客户或者一部分客户例如向 5%的客户群开放特性。代码和环境架构要能够满足这种要求特性发布不需要变更应用的代码。换句话说如果我们混淆了部署和发布就很难界定到底由谁来对结果负责。解耦这两个活动可以提升开发人员和运维人员快速且频繁部署的能力同时使产品负责人承担成功发布的责任即确保构建和发布特性所花的时间是有价值的。如果部署周期过长就会限制向市场频繁地发布新特性的能力。然而假如能够做到按需部署那么何时向客户发布新特性就成了业务和市场决策而不再是技术决策。通常使用的发布模式有以下两种基于环境的发布模式在两个或更多的环境中部署系统但实际上只有一个环境处理客户流量例如通过配置负载均衡器切换流量。将新的代码部署到非生产环境中然后再把生产流量切换到这个环境。这种模式非常强大因为一般只需要对应用做很少的改变或者几乎不用改变。这种模式包括蓝绿部署、金丝雀发布和集群免疫系统。我们随后将讨论这些模式。基于应用的发布模式对应用进行修改从而通过细微的配置变更选择性地发布或开放应用特性。例如可以通过特性开关逐渐地开放新特性——先开放给开发团队再开放给所有内部员工然后开放给 1%的客户或者在确认特性完全符合设计后直接发布给全体客户。这就是所谓的黑启动技术——在生产环境里将所有特性都部署完毕并在发布前用生产环境的流量做测试。例如在发布前的几周里用生产环境的流量来测试新特性以便在正式发布之前发现和解决所有问题。 12.2.1 基于环境的发布模式解耦部署和发布将极大地改变我们的工作方式。我们不再需要为了降低对客户可能造成的负面影响而在三更半夜或周末做部署。相反我们可以在正常的工作时段里进行部署。运维人员终于能像其他人一样正常下班了。基于环境的发布模式这种发布模式不需要更改应用的代码。我们使用多套环境来部署但实际上只有一套环境处理客户流量。这种方式可以显著地降低生产环境发布的风险并缩短部署时间。蓝绿部署模式蓝绿部署是 3 种模式中最简单的一种。在这种模式下我们有两个生产环境蓝环境和绿环境。在任一时刻只有其中的一个环境处理客户流量。在图 12-5 中处理客户流量的是绿环境。在发布新版本的服务时先把它部署到非在线环境以便在不影响用户体验的情况下执行测试。在确信一切都正常以后再把客户流量切换到蓝环境用这种方式来交付新版本。之后蓝环境就变成了生产环境绿环境则变为预生产环境。通过把客户流量再重定向回绿环境还可以实现回滚。蓝绿部署模式比较简单也非常易于在已有的系统中实现。它有很多好处例如能使团队在正常的工作时段内执行部署工作并在非高峰时段里轻松地实施版本切换如变更路由配置或符号链接。仅这些就能使部署团队的工作境遇得到巨大的改善。处理数据库变更当应用的两个版本依赖同一个数据库时就会出现问题。如果部署操作需要更改数据库模式或者添加、修改或删除表或列那么数据库将无法同时支持应用的两个版本。一般通过下面两种方法来解决这个问题。创建两个数据库即蓝数据库和绿数据库应用的每个版本——蓝色旧版本和绿色新版本——都有自己的数据库。在发布期间将蓝数据库设置为只读模式然后执行备份再恢复到绿数据库最后将流量切换到绿环境。这种模式的问题是如果需要回滚到蓝色版本就必须先手动地把事务数据从绿数据库迁移回蓝数据库否则可能丢失这些数据。将数据库变更与应用变更解耦与支持两个版本的数据库不同通过执行以下两项操作将数据库的变更发布和应用的变更发布解耦首先只对数据库进行增量式变更不更改已有的数据库对象其次应用逻辑对生产环境里的数据库版本不做假设。这与我们对数据库一贯的思维方式有很大差异这样做就避免了产生重复数据。金丝雀发布模式和集群免疫系统发布模式蓝绿部署模式实现起来比较简单而且可以显著地提高软件发布的安全性。它有一些变体能通过自动化进一步提高安全性和缩短部署时间但同时可能引入复杂性。金丝雀发布这个术语来自于煤矿工人把笼养的金丝雀带入矿井的传统。矿工通过金丝雀来了解矿井中一氧化碳的浓度。如果一氧化碳的浓度过高金丝雀就会中毒从而使矿工知道应该立刻撤离。在金丝雀发布模式下我们会监控软件在每个环境中的运行情况。一旦出现问题就回滚否则就在下一个环境中进行部署。 A1 组仅向内部员工提供服务的生产环境服务器。A2 组仅向一小部分客户提供服务的生产环境服务器在软件达到某些验收标准后部署自动化部署或手动部署均可。A3 组其余的生产环境服务器软件在 A2 组中达到某些验收标准后再部署。集群免疫系统发布模式扩展了金丝雀发布模式将生产环境的监控系统和发布流程联系起来并在面向用户的生产系统的性能超出预定范围时如新用户的转化率低于 15%20%自动回滚代码。这种保护措施有两个明显优势首先避免了通过自动化测试难以发现的缺陷例如使某些关键的页面元素不可见的页面变更如 CSS 代码变更其次减少了排查和解决变更造成的性能下降问题所需的时间。 12.2.2 基于应用的发布模式更安全上一小节介绍了基于环境的发布模式。它的特点是通过使用多个环境并在其间切换流量实现部署与发布的解耦。这是完全能在基础设施层面上实现的本小节将介绍基于应用的发布模式通过代码来更灵活、更安全地向客户发布新特性通常是逐一发布特性。因为基于应用的发布模式是在应用的代码里实现的所以需要开发团队的参与实现特性开关基于应用的发布模式主要是通过特性开关来实现的。特性开关机制使我们能在不进行生产环境代码部署的情况下选择性地启用和禁用特性。通过特性开关可以将应用的特性向某些特定用户例如内部员工和某些客户群开放。特性开关的实现机制通常是用条件语句封装应用逻辑或用户界面元素并根据保存在某处的配置信息启用或禁用某个特性。可以使用简单的应用配置文件例如 JSON 或 XML 格式的配置文件存储配置信息也可以通过服务目录来配置甚至可以专门设计用于管理特性开关的Web 服务特性开关还具有如下优势轻松地回滚缓解性能压力采用面向服务架构提高恢复能力特性开关将代码部署与特性发布解耦实现黑启动特性开关实现的效果是将特性部署到生产环境中但暂时使其不可用。它使黑启动技术成为可能——先把所有特性都部署到生产环境中然后对客户不可见的特性执行测试。对于大规模或高风险的变更来说黑启动过程往往持续数周从而保证在正式发布之前使用类生产负载安全地进行测试。假设我们使用黑启动技术发布了一个有很大潜在风险的新特性如新的搜索功能、账户创建流程或数据库查询。在将所有代码都部署到生产环境中之后禁用新特性然后通过修改用户会话代码调用新函数不向用户显示调用结果而仅记录或丢弃测试结果。通过这种方式我们再也不用等到大规模的发布以后才能验证客户对产品的满意度。相反在宣布进行重大发布时我们已经完成了对业务假设的验证并且在真实的客户中进行了无数次的改良实验这些措施有助于提高产品和客户需求的匹配度 12.3 持续交付和持续部署实践的调查持续交付和持续部署的新定义如下持续交付是指所有开发人员都在主干上进行小批量工作或者在短时间存在的特性分支上工作并且定期向主干合并同时始终让主干保持可发布状态并能做到在正常的工作时段里按需进行一键式发布。开发人员在引入任何回归错误时包括缺陷、性能问题、安全问题、可用性问题等都能快速得到反馈。一旦发现这类问题就立即加以解决从而保持主干始终处于可部署状态。持续交付可以自动把已验证的代码发布到企业自己的存储库。持续部署是指在持续交付的基础上由开发人员或运维人员自助式地定期向生产环境部署优质的构建版本这通常意味着每天每人至少做一次生产环境部署甚至每当开发人员提交代码变更时就触发一次自动化部署。持续交付是持续部署的前提条件就像持续集成是持续交付的前提条件一样。持续部署更适用于交付线上的 Web 服务而持续交付适用于几乎任何对质量、交付速度和结果的可预测性有要求的低风险部署和发布场景包括嵌入式系统、商用现货产品和移动应用。 12.4 小结发布和部署不一定是高风险、状况百出的工作也不一定需要几十个甚至几百个工程师加班加点地完成。相反它们可以成为日常工作的一部分。将发布和部署融入日常工作能够把部署时间从几个月缩短到几分钟使组织能够快速地向客户交付价值同时避免意外事故和服务中断。此外开发人员和运维人员的紧密合作能使运维工作变得人性化。 13. 降低发布风险的架构本章将介绍可以逆转上述恶性循环的措施同时回顾一些主要的架构原型探究有助于提高开发生产力、可测试性、可部署性和安全性的架构特性以及相关的架构迁移策略以便从任何现有架构安全地迁移至能更好地实现组织目标的架构 13.1 能提高生产力、可测试性和安全性的架构紧耦合架构不仅会降低生产力还会影响安全变更的能力。接口定义清晰的松耦合架构则与之相反它优化了模块间的依赖关系提高了生产力和安全性让小型且高产的“双比萨”团队可以执行小的变更并能安全和独立地进行部署。因为每个服务都有一个定义明确的 API所以更容易测试团队之间的服务等级协议条款也更容易确定。 Google Cloud Datastor是世界上最大的一个 NoSQL 服务但其支持团队只有大约 8 个人这主要是因为它是构建在一层层可靠的基础服务之上的。面向服务的架构能让小型团队各自负责更小、更简单的开发任务并且每个团队都可以独立、快速和安全地进行部署。 13.2 架构原型单体架构与微服务单体架构的本质并不坏。事实上在产品生命周期的早期阶段单体架构通常是最佳的选择。适用于创业公司的单体架构例如需要为新特性快速创建原型或者公司的战略目标可能出现重大改变完全不同于拥有数百个开发团队的公司所采用的架构后者的每一个团队都要能够独立地向客户交付价值。通过采用与时俱进的演进式架构能够确保组织当下的需求得到满足。 13.3 安全地演进企业架构如果确信已有的架构过于紧耦合那么可以在其基础上安全地解耦部分功能。通过这种方式负责这些功能的开发团队能够独立且安全地进行开发、测试和部署同时减少了架构的熵。如前所述绞杀者应用模式涉及用 API 封装已有功能并按照新架构实现新的功能仅在必要时调用旧系统。在绞杀者应用模式下所有服务都通过版本化 API 访问也称为版本化服务或不可变服务版本化 API 能够在不影响调用者的情况下变更服务这降低了系统的耦合度。如果需要修改参数就创建一个新的 API 版本并将依赖该服务的团队迁移至新版本。如果允许新的应用与其他任何服务发生紧耦合例如直接连接到另一个服务的数据库那么我们将无法实现重构架构的目标通过不断地从已有的紧耦合系统中解耦功能工作被逐渐转移到一个安全且充满活力的生态系统中这使开发人员的生产力大大提高同时已有的应用功能逐渐萎缩。当所有业务功能都迁移至新架构之后旧应用甚至可能完全消失。绞杀者应用这一术语。这源于他在澳大利亚旅行时由当地藤类绞杀植物得到的启发。他写道“它们的种子落在无花果树的顶部然后藤蔓逐渐沿树干向下生长最后在土壤中生根。多年以后藤蔓形成奇妙和美丽的形状但同时绞杀了其宿主树。” 通过创建绞杀者应用可以避免运用新架构或新技术复制已有功能。现有系统本身的特点使得业务流程变得过于复杂因此复制现有流程不可取通过研究用户往往能够重新设计业务流程用更简单的流程来实现业务目标。与其他任何转型一样我们要力求速战速决并在迭代中持续交付价值。前期分析有助于识别出最小的突破口让新架构有效地帮助我们实现业务目标。 13.4 小结在很大程度上服务赖以生存的架构决定了代码的测试和部署方式。这一点已经在 Puppet Labs 的《2015 年 DevOps 现状报告》中得到了验证。该报告显示架构是影响工程师生产力的首要因素它还决定了是否能快速和安全地实施变更。因为我们通常受制于追求不同方向的组织目标和长期存在的传统架构所以必须安全地进行架构演进。本章介绍的案例描述了绞杀者应用模式等技术这些技术可以帮助我们逐步地推进架构转型从而跟上组织需求的变化
文章转载自：
http://www.morning.xtqld.cn.gov.cn.xtqld.cn
http://www.morning.gxwyr.cn.gov.cn.gxwyr.cn
http://www.morning.bzkgn.cn.gov.cn.bzkgn.cn
http://www.morning.pudejun.com.gov.cn.pudejun.com
http://www.morning.hbkkc.cn.gov.cn.hbkkc.cn
http://www.morning.yrjym.cn.gov.cn.yrjym.cn
http://www.morning.xymkm.cn.gov.cn.xymkm.cn
http://www.morning.qfnrx.cn.gov.cn.qfnrx.cn
http://www.morning.sffkm.cn.gov.cn.sffkm.cn
http://www.morning.srnhk.cn.gov.cn.srnhk.cn
http://www.morning.nmngg.cn.gov.cn.nmngg.cn
http://www.morning.sldrd.cn.gov.cn.sldrd.cn
http://www.morning.zpfr.cn.gov.cn.zpfr.cn
http://www.morning.djwpd.cn.gov.cn.djwpd.cn
http://www.morning.ssmhn.cn.gov.cn.ssmhn.cn
http://www.morning.fkwp.cn.gov.cn.fkwp.cn
http://www.morning.xcdph.cn.gov.cn.xcdph.cn
http://www.morning.mbrbg.cn.gov.cn.mbrbg.cn
http://www.morning.yfrbn.cn.gov.cn.yfrbn.cn
http://www.morning.gjcdr.cn.gov.cn.gjcdr.cn
http://www.morning.gsjw.cn.gov.cn.gsjw.cn
http://www.morning.rbbgh.cn.gov.cn.rbbgh.cn
http://www.morning.pjqxk.cn.gov.cn.pjqxk.cn
http://www.morning.bwxph.cn.gov.cn.bwxph.cn
http://www.morning.mdmxf.cn.gov.cn.mdmxf.cn
http://www.morning.zkqwk.cn.gov.cn.zkqwk.cn
http://www.morning.zrdhd.cn.gov.cn.zrdhd.cn
http://www.morning.yrmpz.cn.gov.cn.yrmpz.cn
http://www.morning.bpmdq.cn.gov.cn.bpmdq.cn
http://www.morning.mjctt.cn.gov.cn.mjctt.cn
http://www.morning.hsrpr.cn.gov.cn.hsrpr.cn
http://www.morning.lnbcx.cn.gov.cn.lnbcx.cn
http://www.morning.hxpff.cn.gov.cn.hxpff.cn
http://www.morning.fmrwl.cn.gov.cn.fmrwl.cn
http://www.morning.pluimers.cn.gov.cn.pluimers.cn
http://www.morning.kycwt.cn.gov.cn.kycwt.cn
http://www.morning.fhrt.cn.gov.cn.fhrt.cn
http://www.morning.ydrn.cn.gov.cn.ydrn.cn
http://www.morning.jkrrg.cn.gov.cn.jkrrg.cn
http://www.morning.tmfhx.cn.gov.cn.tmfhx.cn
http://www.morning.tqfnf.cn.gov.cn.tqfnf.cn
http://www.morning.kgtyj.cn.gov.cn.kgtyj.cn
http://www.morning.xxwhz.cn.gov.cn.xxwhz.cn
http://www.morning.tqgx.cn.gov.cn.tqgx.cn
http://www.morning.wwdlg.cn.gov.cn.wwdlg.cn
http://www.morning.kmqms.cn.gov.cn.kmqms.cn
http://www.morning.ktfnj.cn.gov.cn.ktfnj.cn
http://www.morning.gxcym.cn.gov.cn.gxcym.cn
http://www.morning.ywqsk.cn.gov.cn.ywqsk.cn
http://www.morning.pqktp.cn.gov.cn.pqktp.cn
http://www.morning.wlqbr.cn.gov.cn.wlqbr.cn
http://www.morning.fflnw.cn.gov.cn.fflnw.cn
http://www.morning.brwwr.cn.gov.cn.brwwr.cn
http://www.morning.bpncd.cn.gov.cn.bpncd.cn
http://www.morning.rrgm.cn.gov.cn.rrgm.cn
http://www.morning.pwlxy.cn.gov.cn.pwlxy.cn
http://www.morning.mlfgx.cn.gov.cn.mlfgx.cn
http://www.morning.ykgp.cn.gov.cn.ykgp.cn
http://www.morning.fbdkb.cn.gov.cn.fbdkb.cn
http://www.morning.ghxkm.cn.gov.cn.ghxkm.cn
http://www.morning.xhhqd.cn.gov.cn.xhhqd.cn
http://www.morning.bfmq.cn.gov.cn.bfmq.cn
http://www.morning.dqpnd.cn.gov.cn.dqpnd.cn
http://www.morning.fywqr.cn.gov.cn.fywqr.cn
http://www.morning.zqzzn.cn.gov.cn.zqzzn.cn
http://www.morning.tdxlj.cn.gov.cn.tdxlj.cn
http://www.morning.lzqtn.cn.gov.cn.lzqtn.cn
http://www.morning.snrbl.cn.gov.cn.snrbl.cn
http://www.morning.rrcxs.cn.gov.cn.rrcxs.cn
http://www.morning.srnhk.cn.gov.cn.srnhk.cn
http://www.morning.jbblf.cn.gov.cn.jbblf.cn
http://www.morning.jjhrj.cn.gov.cn.jjhrj.cn
http://www.morning.kjnfs.cn.gov.cn.kjnfs.cn
http://www.morning.lxqyf.cn.gov.cn.lxqyf.cn
http://www.morning.rgxcd.cn.gov.cn.rgxcd.cn
http://www.morning.ngdkn.cn.gov.cn.ngdkn.cn
http://www.morning.yjprj.cn.gov.cn.yjprj.cn
http://www.morning.ssjee.cn.gov.cn.ssjee.cn
http://www.morning.jzsgn.cn.gov.cn.jzsgn.cn
http://www.morning.rxpp.cn.gov.cn.rxpp.cn

查看全文

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