新发布的根本生存装备 不像玩僵尸毁灭的场景，也不像辩论大刀对抗猎枪，在Java的生产环境中问题是真实存在的，特别是在一个新的发布之后（有备无患嘛）。更进一步说，比起当时 将编码周期缩短至几周或是几天，甚至一天缩短多次，反而现在更容易陷入麻烦。为了避免这些麻烦，你需要完全理解新的代码会对你的系统产生什么影响。是否会 对原有的系统产生破坏？是否会让系统运行迟缓？怎么去解决这些可能出现的问题呢？下面介绍一些工具和架构来彻底破解这些问题。
现在开发生命周期非但不会缩短，每天不断膨胀的日志数据 甚至可以达到GB级别的量级。让我们说说在新发布之后的问题：如果你想及时响应，在没有合适的工具的情况下，想要处理多数据源多服务器的GB量级的数据， 几乎是不可能的。在这样的情况下，除开重型企业内部的工具Splunk和他的SaaS中的竞争对手，如Sumo Logic， Loggly等等。我们依然有提供类似功能的其他选择，因此我们对日志的管理做了一个深入的分析，你可以参照这里。 #1 建立一个可靠的日志管理策略，能帮助你看到的不止是单独的日志文件，能让你在新发布之后快速做出相应。 我们最后发现，在新发布之后的一个有用的日志框架就是开源的ELK stack。因为它是开源免费的，所以被特别提到。
ELK stack包括 ElasticSearch,，Logstash 和Kibana 那么我们所说的 ELK到底是什么呢？它是一个混合体，包括用作搜索和性能分析的elasticsearch，用于日志收集的Logstash和用作前端展现的 Kibana。我们已经用过有一段时间了，依靠它和Redis分析我们的Java日志，它也有被用在开发和BI之中。现在，elasticsearch已经内置于Logstash，Kibana也是一个elasticsearch的产品，这样能让集成和安装更容易。 每当一个新的发布之后，前端会展现出我们对这个应用健康所关心的自定义指标。这些指标会实时更新，并且允许刚交付的代码上传到生产环境后马上就得到监测。 #2 搜索，可视化以及对多数据源日志的聚合，是决定你日志管理工具选择的第一要素。 #3 从一个开发者的角度，评估新的发布的影响也包括BI等方面。 可供选择的工具：
性能监控： 发 布周期被缩短，日志文件越来越大，但这并不是全部。随着用户请求的数量急剧增长，他们都希望达到性能的峰值。如果你不努力优化，简单的日志记录让你只能看 到这么多。这样说来，专用应用程序性能管理工具(APM)已不再被认为是奢侈品,它已经迅速成为一种标准。从本质上说，APM意味着时间需要多长时间来执 行不同的地区代码并完成汇报——要达到这个，可以通过代码检测，日志监控或是包括网络/硬件指标。考虑到后台以及用户设备，首先进入我脑中的两个APM工 具分别是New Relic(最近刚IPO)以及AppDynamics。  左边为AppDynamics，右边为New Relic的主面板 不 管是初创还是成熟的公司，这两个都能满足不同类型的开发者。但是两个都在走IPO,在经历巨大的增长后，产品线越来越模糊。这个选择不是很清晰，但是你不 能陷入误区，即On premise = AppDynamics。相反，这是一个独立的需求，它依赖于谁更适合你的站点（即它们提供的所有特性就是你实际上想要使用的）。看看我们最近发布的关于二者的分析报告，点击这里。 我 们最近发布的另外两个工具是Ruxit（由Compuware开发）和DripStat（Chronon Systems开发），它们每一个都来自由New Relic开创的尝试自己解决SaaS监控市场的大公司。为了深入JVM硬核内部，jClarity和Plumbr也绝对值得一试。 #4：新的发布有可能影响你应用的性能使之运行变慢。APM工具可以提供你应用健康的总体情况。 可供选择的工具： 新的成员： 产品调试 发 布周期短了，日志文件变大了，用户请求增多……允许犯错误的余地几乎不存在了。但当错误真的到来时，你需要能够马上解决掉。大规模的生产环境，每天可以从 成百上千个不同的代码处产生无数的错误。虽然有些错误时不重要的，但有些可能对你的应用产生致命的影响，并影响你所接触不到的终端用户。另外，为了鉴别和解决这些错误，你必须依赖于你的日志或是日志管理工具去查看错误的发生，更不用说如何修复它。 有了Takipi，你能够知道最有可能出问题且需要优化的地方，并且能得到怎么取解决每个问题的可行的信息。
|
