场景和解决方案.docx

场景和解决方案场景和解决方案篇一：业务场景 3：_专用链路分析解决方案深信服 APM 专线质量分析解决方案一、需求背景-为什么需要对专线进行监控和分析？ 大型企事业单位分支机构日益增多，越来越多的组织机构通过在总部构建数据中心，让分支机构通过专线（SDH或 VPN 等相关技术）来远程访问总部的业务系统和数据资源来实现协同办公这样的集中式部署可以有效降低成本，提高组织的核心竞争力 但是在日常的专线网络运维和管理过程中，我们往往面临如下困扰 ? 无法获知当前专线的流量构成及网络时延丢包等指标 ? 分支用户投诉专线缓慢，无法进行原因排查 ? 无法实现专线中断的风险预警 ? 针对专线网络的升级扩容及优化缺乏有效的数据支撑 二、深信服 APM 专线质量监控解决方案 应用场景： ? 拥有众多分支机构的政府机构、大企业、金融等客户 ? 分支机构通过专线与总部互联 ? 专线承载较为重要的业务系统，如 ERP、财务系统、OA 等 ? 专线租金较为高昂，专线带宽需要合理利用 三、APM 专线质量分析方案价值方案价值： ? 提供专线时延、丢包、抖动等 SLA 指标 ? 提供专线流量分析，帮助用户准确掌握当前流量分布， 为下一步网络扩容提供依据 ? 发现专线中的异常事件，降低专线中断风险 ? 当专线出现故障风险时，可提前预警， 帮助用户规避业务风险。

四、APM 专线质量分析方案技术优势 内建网络质量健康度评分模型 深信服提供的 APM（应用性能管理）产品，聚焦用户所关注的专线网络及专线所承载的应用系统，针对网络性能、应用性能进行建模实时质量监控，并提供进一步的性能分析报告，提升应用系统的稳定性和访问体验质量 分析专线流量构成 如用户通过专线访问总部数据中心业务，专线流量分布是否合理，是否需要扩容；有无异常事件，有无中断风险等，APM 都可以按照用户需求进行友好的呈现分析 分析专线性能 APM 提供专线性能的 IP SLA 建模分析监控，此外提供定期的专线运行分析报告，除此之外，当专线及专线承载的业务出现故障风险时，可提前预警，帮助用户规避业务风险 领先的应用层网络流量识别及分类技术 网络应用极其丰富，由此引发各种管理和安全问题识别是管理的基础，全面的应用识别帮助管理员透彻了解网络应用现状和用户行为，保障管理效果但基于 Flow 技术的流量可视化无法做到 7 层可视，给用户的管理带来了一定困扰深信服将在 7 层应用流量识别方面的技术积累融入了 APM 中，采用多种应用识别技术，全面识别各种应用流量主要包括： 应用规则识别库：APM 拥有国内最大的应用识别库，该库由深信服应用规则研发团队定期维护，保证库处于最新状态；该库支持 900 种以上网络主流应用，XX 条以上规则 能识别 40 种以上 IM、50 种以上 P2P/P2P 流媒体、100种以上游戏、20 种以上 OA、15 种以上网银、20 种以上股票行情软件、15 种以上股票交易软件、10 种以上木马、10 种以上代理软件。

深度内容检测：IM 聊天、炒股、网络游戏、流媒体、P2P 应用、Email、常用 TCP/IP 协议等，基于数据包特征精准识别，且支持管理员自行定义新规则，以及深信服科技及时更新和快速响应； 智能识别：种类泛滥的 P2P 行为，静态“应用识别规则”已经捉襟见肘，通过 P2P 智能识别，识别不常见、未来可能出现的 P2P 行为 专线质量分析与逻辑拓扑配合，效果更直观 APM 提供逻辑拓扑功能，可以将专线质量监控与拓扑显示结合起来当某条专线（分支）变慢或断线，可以直观的在拓扑上呈现 专线变慢或断线预警 APM 智能预警功能默认含线路流量异常告警、区域网络异常告警、线路网络异常告警、网络攻击告警、区域流量异常告警、系统可用性告警、系统响应缓慢告警等信息，并可根据 APM 设备监控、应用系统监控、流量监控等信息为特定的服务器量身定做自定义告警策略，提高管理的效率及响应及时性 当用户所关注的专线网络访问变慢或断线，APM 可以通过短信或邮件实现告警 五、深信服 APM 简介 APM（Application Performance Management，应用性能管理）是一种较为新颖的网络及应用管理理念，侧重对企业的关键网络及其承载的关键业务应用进行监控、分析，提高关键网络、应用的可靠性和服务质量，保证终端用户获得良好的访问体验。

篇二：理解 SOA 体系结构中 ESB 场景和解决方案 引言 最新的 IT 集成是使用 Web 服务技术实现面向服务的体系结构（SOA） ，有许多优秀的文章讲述了该技术的好处和相关的实践最近，企业服务总线 （Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件然而，有必要阐明 ESB 究竟是一个产品、技术、标准，还是别的什么特别是，当前是否可以构建 ESB？如果这样，该如何构建？ 本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性为了达到此目的，需要将多种功能集中起来并加以分类然而，并不是 ESB 能够传递值的每一种情形都需要所有的功能 本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术 随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。

同样，可见的 ESB 产品的可用性和功能也日趋完善因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB 功能和技术的最初应用，并且阐述如何选择循序渐进的方法 ESB 在 SOA 内的工作角色 虽然我不打算深入讨论 SOA 的定义，但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的： 1.利用显式的与实现无关的接口来定义服务[接口无关性] 2.利用强调位置透明性和可互操作性的通信协议[通信透明性] 3.封装可重用业务功能的服务的定义[重用] 图 1 说明了这些原则注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术图 1: SOA 的原则 为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。

这样的服务路由和替代是 ESB 的许多功能中的一部分 ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能因此，它将当今正在使用的主要企业集成模式组合成一个实 体ESB 为 SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的 ESB 功能模型部分中所述 ESB 结构 ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke） 然而，这并不是真正的差别正在研究两个不同的问题：控制的集中和基础架构的分布ESB 和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署图 2 展示了这一点 毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。

使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围 图 2: 分布式 ESB 基础架构的集中控制1. 我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特 别是与 Service Directory、Business Service Choreography[动 作设计]、以及 Business-to-Business (B2B) Gateway 这些组件之 间的关系由于上述 SOA 原则对这些组件并没有严格的要求，所以 我们可以将它们视为可选组件图 3 展示的 SOA 说明了这些组件之 间的关系 图 3: SOA 中的 ESB 角色ESB 需要某种形式的服务路由目录（service routing[路由] directory）来路由服务请求然而，SOA 可能还有单独的业务服务目录（business service directory） ，其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。

这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的 Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过 ESB 将业务流程公开为客户端可用的其他服务然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术 最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用这有助于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 篇三：华为 TDD-LTE 大话务场景解决方案 v3-XX0913一、 设备能力描述 华为区域在网设备和两个版本，按照省公司升级计划，本月底将完成全网版本的收编工作，故所有产品规格以为准进行介绍 2 大话务场景解决方案 宏站覆盖场景 F 新建/升级宏站（单频网） 大话务解决方案： a) 共站建设 D 频段宏站； b) 开启华为 MLB 负载均衡算法（小区级） ； 资源需求： a) D 频段基站硬件设备*1 套； b) MLB 负载均衡算法 LICENSE（小区级） 。

实施方法：a) 开通 D 频段新建站，并增加 D 频段天馈或更换 FAD宽频天线，使 F、D 频段共用 一套天馈； b) License 打上后，开启 MLB 负载均衡算法 通过华为负载均衡算法，将用户数均匀分布在共站同覆盖的 2 个小区下，从而达到提升大话务区域容量的目的按照此方案实施，双频网建成后共覆盖区域，用户数容量为单频网 2 倍左右 D1 新建站（单频网） 大话务解决方案： a) 共站建设 D2 频点小区； b) 开启华为 MLB 负载均衡算法（小区级） ； 资源需求： a) 基带板*1； b) 双载波 license（小区级） ； c) MLB 负载均衡算法 LICENSE（小区级） 实施方法：a) 上站添加基带板，后台添加小区数据，激活小区；b) License 打上后，开启 MLB 负载均衡算法 通过华为负载均衡算法，将用户数均匀分布在共站同覆盖的 2 个。