在你的安排内部，Atlassian 的运用情况今日看起来可能与开始现已大不相同了。用户数和问题数都在不断添加，安排面对着扩展带来的压力
。 怎么削减部分间的隔膜促进团队协作？跟着运用量的添加，怎么坚持体系高功能作业？（文末有彩蛋）
当你的 JIRA Software 实例从10个用户添加到10,000个用户时，你会怎么做
？这正是美国抢先的医疗信息技术供货商 Cerner 副总裁 Brian Wallace 和常识架构师 Mike Damman 面对的问题，他们需求满意不断添加的团队需求。怎么保证如此巨大的实例的可靠性？能够采纳哪些办法削减停机影响？
应战一： 在全球范围内扩展 Jira Software
Cerner 有三个 JIRA Software Server 联合实例，不计其数的开发者每天的每个时段全球范围内都在运用这些实例。JIRA Software 敏捷成为团队作业的要害运用，每一分钟的停机或功能下降都会使 Cerner 团队成员难以更好地服务于客户。他们需求一种供给高可用性的处理方案。
应战二：高可用性的危险
Cerner 运用 Zabbix 和 Splunk 监控 Jira 实例，为了供给真实的高可用，他们确认了一个需求当即处理的问题，便是 REST API 的乱用。日志剖析显现，团队成员运用 REST API 获取实时状况更新，不管团队知心意否，他们每一秒都在读取 JIRA Software 实例。Cerner 不期望约束用户创立自定义仪表板或自行获取所需数据，但明显应该采纳一些办法来处理问题。
处理方案：智能分流流量
-
节点1 ：外部 REST API 节点
-
节点2和3：正常运用节点
-
TAM 开始以为最好运用负载均衡器，将一切带有"/rest"的恳求路由到 REST API 节点。可是，经过一些测验后，他们发现 REST API 也在 JIRA Software 中运用，包含登录页面，所以只运用 “/rest” 意味着依然会将 REST API 流量与正常运用混在一同。
经过与其他一些 TAM 协作，他们发现，能够经过在恳求中查找 “/rest” 而且用 HTTP referrer header 检索到恳求产生的原始方位，阻隔 REST API 恳求。假如有人企图登录 JIRA Software 或现已在用 JIRA Software，将被定向或保留在正常运用节点上。不然，假如有人或机器在恳求 REST API，将被定向到 REST API 节点。
经过几轮测验，Cerner 在2015年10月正式上线了 JIRA Software Data Center。
完成规划功能
在施行 Data Center 装备第一周，REST API 节点流量是其他两个节点的4倍。与单一服务器实例比较，呼应时刻更快，非办理节点的 CPU 运用率下降，而且在将 Jira Software 扩展到数千个新用户之后，2016年没有呈现一次意外中止。
呼应时刻
Cerner 需求保证在持续添加用户的一起保持或改进运用程序呼应时刻。这种架构标明，
Cerner 能够将呼应时刻减缩近一半 - 从150秒削减到80秒
。即便在峰值流量期间，特别是在加载页面时，也能坚持稳定的呼应时刻。
“ 2014年，咱们呈现了55次停机，2015年，咱们经过扩展将停机数量削减到7次。现在有了 Jira Software Data Center，2016年，尽管运用量一直在添加，可是没有呈现一次意外停机。”
MIKE DAMMAN
，常识架构师，
CERNER
彩蛋：
