灾难恢复规划:关键型应用程序应该有适当的灾难恢复规划。我信任hot-hot型而不是hot-standby(热备份)型的冗余环境。如果备份不能运行该怎么办?如果出现故障，有多少服务器实例才足以维持峰值负载?关于这方面的详细信息也必须在文档中注明。所有这些可以确保在出现故障时能够有一个运行良好的环境，而保护业务是底线。
统一管理:我曾经在一些机构中看到他们用一个操作小组来管理多个WebLogic域。这样的环境是难于维护和管理的。考虑需要进行更新的场景。还有监控——这是一项日常操作任务——必须查看多个WebLogic Server控制台以收集信息。我的建议是，在可能的地方对类似的应用程序创建多个集群而不是多个域。集群提供对应用程序的固有隔离级别，这会产生较少的域以及更易于管理的环境。
操作是面向流程的:对环境的操作很大程度上是面向流程的，且需要进行详细的记录。错误模式和正确的解决方案的记录都是一个动态过程。环境进行升级和打补丁的停机时间必须符合高可用性的业务需求。必须为维护设置适当的过程。还要定义逐步升级的过程，并写入文档。作为部署过程的一部分，还应该采用域模板，以便产生跨不同环境的一致域。
提供透明性:一个管理良好的环境需要有针对关键性业务破坏的报警机制。在问题诊断时，服务器日志中的信息必须有一定的透明度。应用程序必须记录有助于问题诊断的关键信息。在问题诊断时，可以使用诸如来自Splunk之类的工具来聚合来自服务器环境中不同日志的信息。此外，预期和实际的关键性技术指标也应该被收集并关联起来。例如，在容量规划期间，可以基于业务需求预测特定数目的并发用户，而这个数字可能与生产环境中实际得到的数字不同。这类技术指标应该定期报告，以方便以后的环境调优。
结束语
在本文中，我介绍了一种经过大大简化的方法，用于将驻留在WebLogic上的应用程序转化为SOA中的资产。此外，我没有谈到的其他领域(比如数据库、外部系统)也需要进行分析和研究。上述概念也可以应用于这些系统。这些特性都带有相关的成本，因此必须分析实现它们的投资回报(ROI)。最后您将得到一个可以满足业务和功能需求的环境，就可以很好地实现SOA了。本文并未涵盖所有的SOA要素，但是它提出了一个用于满足复杂的WebLogic环境中的某些SOA需求的解决方案。
文章来源于领测软件测试网 https://www.ltesting.net/
