什么是魔兽私人服务器

大家好，写这篇文章的时候，我已经不是9c的员工了，终于可是说出自己心中的话了，做客服XX部的经理16个月零9天，除了周Ri以外，每天的心情都很压抑．除了压抑还是压抑，看到的所有美好的事物在我的脑海里都扭曲了．早在wow进入内测的时候，从美国派来了一个25人的技术／服务人员组，初期对我们进行了大量的培训，不得不承认，做了这么多年，很多东西我都没接触到人家那么深，尤其是其中有个23岁的小伙子，Christin，彻底否定了我以前学过的很多东西，那段时光是美好的．．．（这里就不多说了）．按合同要求，所有服务器包括相应内部处理程序，必须从美方一次性付款购买（很多公司因为这个门槛太高放弃了），这在当初的谈判会上的争论是相当激烈的，而我们的XXX老总最后也答应了这个要求，知道2区所有服务器开放完毕，所有设备都已经到位，资金全部从上海银行贷款，应该说，走到这步，我当时真的很高兴，看到了公司的潜力，看到了自己的未来．公测结束后，相应的问题表现出来了，将近60％的玩家因为收费暂停或者放弃了wow,并且第一波营销（纪念版冲值卡，各大城市巡回演出等等）受挫，业绩直线下滑，好几个部门的负责人被迫辞职，我在客服能 幸免遇难，也是幸运中的幸运了．为了扭转这样的形势，公司再次贷款，加大了投入的力度，但是事实还是无法改变，（ps 在这里说一个细节，服务器在线最高峰值纪录是18400（约等于）人，也就是说，不是像你们所想像的那样，每组服务器容纳60000个玩家）．自从央视报道青少年沉迷wow后，客服的压力瞬间增大，每天成千个家长的电话，我们服务人员8小时连去WC的时间都没有．国家文化部随之建议推出防沉迷系统，对9c的打击真的很大，大到银行派专人监控9C的财务报表，并且暂时性停止对9C的贷款．美方的销售人员在调查的了中国24个城市后做出决定，要求9c增加开放服务器，满足更多玩家的要求，关于设备的问题争论了好几个星期，才终于允许9C自己购买设备，于是你们的恶梦和我的恶梦也就开始了，多了我不想说，心细的玩家自己能发现，哪怕是在人最少的二区PVE服务器，也会很卡，哪怕当时在线人数＜2000人，为什么呢？因为2区个6区在同一个机房，4个PVE和2个PVP共用一组服务器，现在明白了吗？没有新的设备，没有任何更新．关于5区的问题更严重，用N年前旧的服务器在工作，虽然在当时，这组服务器是被誉为#$#@$#@$#,但是对于wow这样高质量的游戏来说，只能用”不配”二字形容．还有些东西大家是不知道的，比如 如何维护服务器，所有的技术人员对美方的技术不熟悉，深造人员去的一半就没再回来，维护只是关机，备份，抽取纪录等等，大概1小时的工作．而和美方当初培训时候的5小时维护，硬件软件的检测，真是小巫见大巫了．现在离开了9c,离开了上海，虽然渺茫了，但是终于离开了那种压抑的环境，特别特别喜欢看最近出的部片子 求求你表扬我，作为wow的客服人员，每个人都是这么想的，请大家不要在跟我们这些客服人员生气，我们为了吃饭，什么都不能多说，请不要在辱骂GM，他们的谈话纪录每天都被审查．员工合同有这么一条，每月增加补助400元，当解约后3年不得从事相同行业的工作，不得泄露公司内部受控文件，及信息．．．．．．．．．．9c你想当我爸爸？儿子我现在长大了，你管不着 、 我匿名写下了这封帖子，是因为我暂时并还不想丢掉饭碗。在春节前些Ri子，暴雪中国考察队在访问中国各大城市后，要求9C新增区并在每个区都增加新服务器，但是由于9C资金不足，再加上防沉迷系统的压制，无法自费购买由美国原装的服务器，几个星期的激烈会议后，暴雪同意9C自行购买其他服务器，但暴雪中断了9C的技术支持，也就是说，暴雪在更新版本及发现故障后不给予9C任何帮助，9C也因为种种原因，在春节后网络系统一直没有更新，服务器的运转质量也越变越差，9C自行对服务器的维护，仅仅不到1个小时，按暴雪原技术要求，需要检查网络系统，服务器设备，每Ri备份，每台服务器拥有2个备用电源，而 9C的维护仅仅每周一次备份，其余工作没有执行，也有部分原因，因为9C的专业工程师仅仅只有70人，大多为新人，根本检查不出问题。然后再告诉你们几件事：细心的人会发现，5区的每个服务器基本从早排到晚，而上线后发现人数并不如服务器所显示的那么膨胀，其实所谓的5区就是原奇迹13-40区的服务器，其实5区的上线人数还不及4区的一半多，终于明白了吧？9C对于暴雪让其自行购买服务器，也就是说9C根本没有购买服务器，把奇迹并区，腾出3分之2的服务器来运行WOW，我原以为用不到2个星期就会崩溃，居然能用了4个月，而且还没有任何的维护，真是奇迹。不过现在5区已经彻底崩溃。。。服务器的上限改成了1800，就好象用128的内存玩WOW一样的概念。6区，其实就是2区，在2区的空间里划分出了一半，那就是6区，在2区和6区的玩家，应该非常清楚，服务器是什么状况，3区的服务器在一个小房间里，其实只是比其他房间小，也有400多平方，但只有8台服务器，也就是说，每6个游戏中的服务器，实际上是合在一个机器里的。我只是想告诉大家一些确切的消息，也许我很快就会离开，放弃这份压抑的工作但我最后有个请求，GM每天的聊天记录和电话都是有记录的，无法跟玩家说出真心的话，希望大家不要用辱骂的语气和GM对话，我们真的很无奈，GM也是人，KAO别人吃饭的一个人。 另外一个小道消息：据小道消息说，是因为9C内部中一些对9C不满的离职员工，入侵到整个9C的网络系统，在3区的几个服务器开始下手，在成功破坏多组服务器的数据后被中心监控台发现，然后关闭在同一线路上的24台服务器，15号早上11点确认只有2组服务器没有任何问题，其他的服务器数据都大大小小有些异常，逻辑数据硬盘已经遭到毁灭性的攻击无法继续使用了，更换后发现备份文件也遭到筛改，目前正在努力的恢复，根据里面的人透露，备份文件基本可以完全恢复，不过需要大量的时间，大多数据需要手动修改，里面的工作人员已经2天没有休息了 看了半天入了神，心想磁铁一定被删除，就试着刷新了一下，果然指定帖子不存在或被删除．幸亏在此之前我把文章复制了．请大家把帖子传下去． 这是9C内部关于维护的通知~原文如下: 关于暂停魔兽世界服务器的通知 鉴于最近奇迹世界公测后玩家大量涌入引起服务器瘫痪以至玩家流失的情况，技术部拟定于黄金周期间暂停魔兽世界服务器转做奇迹世界服务器以保证奇迹世界公测的顺利进行。 具体CAO作如下： 4 月 26 Ri (周四)凌晨 1:00 开始，原魔兽世界第四大区编号W4QTN5325--W4QTN5329机组正式转作奇迹世界服务器。编号W4QTN5330--W4QTN5332机组做为预备机组，防止出现假期期间玩家大量涌入后服务器初量不足的局面。 4 月 28 Ri (周六)凌晨 1:00 开始，原魔兽世界第四大区编号W4QTN5325--W4QTN5329机组停止运行奇迹世界，并做好相关维护保证魔兽世界第四大区的准时开放。编号W4QTN5330--W4QTN5332机组仍做为奇迹世界预备机组。 4 月 28 Ri (周六)凌晨 1:00 开始，原魔兽世界第六大区编号W6QTN5341--W6QTN5345机组正式转作奇迹世界服务器。 4 月 30 Ri (周一)凌晨 1:00 开始，原魔兽世界第六大区编号W6QTN5346--W6QTN5348机组做为预备机组。原魔兽世界第四大区编号W4QTN5330--W4QTN5332机组停机维护。 原魔兽世界第六大区服务器的停机时间与魔兽世界第六大区的开放时间另行通知。 请魔兽世界运营团队与奇迹世界运营团队相互协作，做好服务器的相关备份工作，避免游戏数据丢失的情况出现，顺利完成奇迹世界黄金周期间的预期指标。 特此通告。 第九城市网络运营技术部 2007424 目前魔兽世界游戏的代理，9城， 副： 引用: 1．Launcher里面的值是N/A or数值？ 2．所在城市、所使用网络连接方式？ 3．一个服务器还是所有服务器都不可以？ 4．登陆其他区是否正常？ 5．请在开始-运行-cmd 输入命令tracert -d cn4gruntwowchinacom。（请玩家务必完成此步骤并跟贴贴出结果） 同时，也建议您向当地ISP询问问题，谢谢！！！ 魔兽世界官方网站：>

适用版本: Kubernetes v122 [stable]

一个完整描述的目标并不是一个完整的对象，仅包括能体现用户意图的字段和值。 该目标（intent）可以用来创建一个新对象， 也可以通过服务器来实现与现有对象的合并。

系统支持多个应用者（appliers）在同一个对象上开展协作。

“字段管理（field management）”机制追踪对象字段的变化。 当一个字段值改变时，其所有权从当前管理器（manager）转移到施加变更的管理器。 当尝试将新配置应用到一个对象时，如果字段有不同的值，且由其他管理器管理， 将会引发冲突。 冲突引发警告信号：此 *** 作可能抹掉其他协作者的修改。 冲突可以被刻意忽略，这种情况下，值将会被改写，所有权也会发生转移。

当你从配置文件中删除一个字段，然后应用这个配置文件， 这将触发服务端应用检查此字段是否还被其他字段管理器拥有。 如果没有，那就从活动对象中删除该字段；如果有，那就重置为默认值。 该规则同样适用于 list 或 map 项目。

服务器端应用既是原有 kubectl apply 的替代品， 也是控制器发布自身变化的一个简化机制。

如果你启用了服务器端应用，控制平面就会跟踪被所有新创建对象管理的字段。

用户管理字段这件事，在服务器端应用的场景中，意味着用户依赖并期望字段的值不要改变。 最后一次对字段值做出断言的用户将被记录到当前字段管理器。 这可以通过发送 POST、 PUT、 或非应用（non-apply）方式的 PATCH 等命令来修改字段值的方式实现， 或通过把字段放在配置文件中，然后发送到服务器端应用的服务端点的方式实现。 当使用服务器端应用，尝试着去改变一个被其他人管理的字段， 会导致请求被拒绝（在没有设置强制执行时，参见冲突）。

如果两个或以上的应用者均把同一个字段设置为相同值，他们将共享此字段的所有权。 后续任何改变共享字段值的尝试，不管由那个应用者发起，都会导致冲突。 共享字段的所有者可以放弃字段的所有权，这只需从配置文件中删除该字段即可。

字段管理的信息存储在 managedFields 字段中，该字段是对象的 metadata 中的一部分。

服务器端应用创建对象的简单示例如下：

上述对象在 metadatamanagedFields 中包含了唯一的管理器。 管理器由管理实体自身的基本信息组成，比如 *** 作类型、API 版本、以及它管理的字段。

Note: 该字段由 API 服务器管理，用户不应该改动它。

不过，执行 Update *** 作修改 metadatamanagedFields 也是可实现的。 强烈不鼓励这么做，但当发生如下情况时， 比如 managedFields 进入不一致的状态（显然不应该发生这种情况）， 这么做也是一个合理的尝试。

managedFields 的格式在 API 文档中描述。

管理器识别出正在修改对象的工作流程（在冲突时尤其有用）, 管理器可以通过修改请求的参数 fieldManager 指定。 虽然 kubectl 默认发往 kubectl 服务端点，但它则请求到应用的服务端点（apply endpoint）。 对于其他的更新，它默认的是从用户代理计算得来。

此特性涉及两类 *** 作，分别是 Apply （内容类型为 application/apply-patch+yaml 的 PATCH 请求） 和 Update （所有修改对象的其他 *** 作）。 这两类 *** 作都会更新字段 managedFields，但行为表现有一点不同。

Note:

不管你提交的是 JSON 数据还是 YAML 数据， 都要使用 application/apply-patch+yaml 作为 Content-Type 的值。

所有的 JSON 文档 都是合法的 YAML。

例如，在冲突发生的时候，只有 apply *** 作失败，而 update 则不会。 此外，apply *** 作必须通过提供一个 fieldManager 查询参数来标识自身， 而此查询参数对于 update *** 作则是可选的。 最后，当使用 apply 命令时，你不能在应用中的对象中持有 managedFields。

一个包含多个管理器的对象，示例如下：

在这个例子中， 第二个 *** 作被管理器 kube-controller-manager 以 Update 的方式运行。 此 update 更改 data 字段的值， 并使得字段管理器被改为 kube-controller-manager。

如果把 update *** 作改为 Apply，那就会因为所有权冲突的原因，导致 *** 作失败。

由服务器端应用实现的合并策略，提供了一个总体更稳定的对象生命周期。 服务器端应用试图依据负责管理它们的主体来合并字段，而不是根据值来否决。 这么做是为了多个主体可以更新同一个对象，且不会引起意外的相互干扰。

当用户发送一个“完整描述的目标”对象到服务器端应用的服务端点， 服务器会将它和活动对象做一次合并，如果两者中有重复定义的值，那就以配置文件的为准。 如果配置文件中的项目集合不是此用户上一次 *** 作项目的超集， 所有缺少的、没有其他应用者管理的项目会被删除。 关于合并时用来做决策的对象规格的更多信息，参见 sigsk8sio/structured-merge-diff

Kubernetes 116 和 117 中添加了一些标记， 允许 API 开发人员描述由 list、map、和 structs 支持的合并策略。 这些标记可应用到相应类型的对象，在 Go 文件或在 CRD 的 OpenAPI 的模式中定义：

若未指定 listType，API 服务器将 patchMergeStrategy=merge 标记解释为 listType=map 并且视对应的 patchMergeKey 标记为 listMapKey 取值。

atomic 列表类型是递归的。

这些标记都是用源代码注释的方式给出的，不必作为字段标签（tag）再重复。

在极少的情况下，CRD 或者内置类型的作者可能希望更改其资源中的某个字段的 拓扑配置，同时又不提升版本号。 通过升级集群或者更新 CRD 来更改类型的拓扑信息与更新现有对象的结果不同。 变更的类型有两种：一种是将字段从 map/set/granular 更改为 atomic， 另一种是做逆向改变。

当 listType、mapType 或 structType 从 map/set/granular 改为 atomic 时，现有对象的整个列表、映射或结构的属主都会变为这些类型的 元素之一的属主。这意味着，对这些对象的进一步变更会引发冲突。

当一个列表、映射或结构从 atomic 改为 map/set/granular 之一 时，API 服务器无法推导这些字段的新的属主。因此，当对象的这些字段 再次被更新时不会引发冲突。出于这一原因，不建议将某类型从 atomic 改为 map/set/granular。

以下面的自定义资源为例：

在 specdata 从 atomic 改为 granular 之前，manager-one 是 specdata 字段及其所包含字段（key1 和 key2）的属主。 当对应的 CRD 被更改，使得 specdata 变为 granular 拓扑时， manager-one 继续拥有顶层字段 specdata（这意味着其他管理者想 删除名为 data 的映射而不引起冲突是不可能的），但不再拥有 key1 和 key2。因此，其他管理者可以在不引起冲突的情况下更改 或删除这些字段。

默认情况下，服务器端应用把自定义资源看做非结构化数据。 所有的键值（keys）就像 struct 的字段一样被处理， 所有的 list 被认为是原子性的。

如果自定义资源定义（Custom Resource Definition，CRD）定义了一个 模式， 它包含类似以前“合并策略”章节中定义过的注解， 这些注解将在合并此类型的对象时使用。

控制器的开发人员可以把服务器端应用作为简化控制器的更新逻辑的方式。 读-改-写 和/或 patch 的主要区别如下所示：

强烈推荐：设置控制器在冲突时强制执行，这是因为冲突发生时，它们没有其他解决方案或措施。

除了通过冲突解决方案提供的并发控制， 服务器端应用提供了一些协作方式来将字段所有权从用户转移到控制器。

最好通过例子来说明这一点。 让我们来看看，在使用 Horizo ntalPodAutoscaler 资源和与之配套的控制器， 且开启了 Deployment 的自动水平扩展功能之后， 怎么安全的将 replicas 字段的所有权从用户转移到控制器。

假设用户定义了 Deployment，且 replicas 字段已经设置为期望的值：

application/ssa/nginx-deploymentyaml

并且，用户使用服务器端应用，像这样创建 Deployment：

然后，为 Deployment 启用 HPA，例如：

现在，用户希望从他们的配置中删除 replicas，所以他们总是和 HPA 控制器冲突。 然而，这里存在一个竟态： 在 HPA 需要调整 replicas 之前会有一个时间窗口， 如果在 HPA 写入字段成为所有者之前，用户删除了replicas， 那 API 服务器就会把 replicas 的值设为 1， 也就是默认值。 这不是用户希望发生的事情，即使是暂时的。

这里有两个解决方案：

首先，用户新定义一个只包含 replicas 字段的配置文件：

application/ssa/nginx-deployment-replicas-onlyyaml

用户使用名为 handover-to-hpa 的字段管理器，应用此配置文件。

在此时间点，用户可以从配置文件中删除 replicas 。

application/ssa/nginx-deployment-no-replicasyaml

注意，只要 HPA 控制器为 replicas 设置了一个新值， 该临时字段管理器将不再拥有任何字段，会被自动删除。 这里不需要执行清理工作。

通过在配置文件中把一个字段设置为相同的值，用户可以在他们之间转移字段的所有权， 从而共享了字段的所有权。 当用户共享了字段的所有权，任何一个用户可以从他的配置文件中删除该字段， 并应用该变更，从而放弃所有权，并实现了所有权向其他用户的转移。

由服务器端应用实现的冲突检测和解决方案的一个结果就是， 应用者总是可以在本地状态中得到最新的字段值。 如果得不到最新值，下次执行应用 *** 作时就会发生冲突。 解决冲突三个选项的任意一个都会保证：此应用过的配置文件是服务器上对象字段的最新子集。

这和客户端应用（Client Side Apply） 不同，如果有其他用户覆盖了此值， 过期的值被留在了应用者本地的配置文件中。 除非用户更新了特定字段，此字段才会准确， 应用者没有途径去了解下一次应用 *** 作是否会覆盖其他用户的修改。

另一个区别是使用客户端应用的应用者不能改变他们正在使用的 API 版本，但服务器端应用支持这个场景。

客户端应用方式时，用户使用 kubectl apply 管理资源， 可以通过使用下面标记切换为使用服务器端应用。

默认情况下，对象的字段管理从客户端应用方式迁移到 kubectl 触发的服务器端应用时，不会发生冲突。

Caution:

保持注解 last-applied-configuration 是最新的。 从注解能推断出字段是由客户端应用管理的。 任何没有被客户端应用管理的字段将引发冲突。

举例说明，比如你在客户端应用之后， 使用 kubectl scale 去更新 replicas 字段， 可是该字段并没有被客户端应用所拥有， 在执行 kubectl apply --server-side 时就会产生冲突。

此 *** 作以 kubectl 作为字段管理器来应用到服务器端应用。 作为例外，可以指定一个不同的、非默认字段管理器停止的这种行为，如下面的例子所示。 对于 kubectl 触发的服务器端应用，默认的字段管理器是 kubectl。

如果你用 kubectl apply --server-side 管理一个资源， 可以直接用 kubectl apply 命令将其降级为客户端应用。

降级之所以可行，这是因为 kubectl server-side apply 会保存最新的 last-applied-configuration 注解。

此 *** 作以 kubectl 作为字段管理器应用到服务器端应用。 作为例外，可以指定一个不同的、非默认字段管理器停止这种行为，如下面的例子所示。 对于 kubectl 触发的服务器端应用，默认的字段管理器是 kubectl。

启用了服务器端应用特性之后， PATCH 服务端点接受额外的内容类型 application/apply-patch+yaml。 服务器端应用的用户就可以把 YAMl 格式的 部分定义对象（partially specified objects）发送到此端点。 当一个配置文件被应用时，它应该包含所有体现你意图的字段。

可以从对象中剥离所有 managedField， 实现方法是通过使用 MergePatch、 StrategicMergePatch、 JSONPatch、 Update、以及所有的非应用方式的 *** 作来覆盖它。 这可以通过用空条目覆盖 managedFields 字段的方式实现。以下是两个示例：

这一 *** 作将用只包含一个空条目的列表覆写 managedFields， 来实现从对象中整个的去除 managedFields。 注意，只把 managedFields 设置为空列表并不会重置字段。 这么做是有目的的，所以 managedFields 将永远不会被与该字段无关的客户删除。

在重置 *** 作结合 managedFields 以外其他字段更改的场景中， 将导致 managedFields 首先被重置，其他改变被押后处理。 其结果是，应用者取得了同一个请求中所有字段的所有权。

Caution: 对于不接受资源对象类型的子资源（sub-resources）， 服务器端应用不能正确地跟踪其所有权。 如果你对这样的子资源使用服务器端应用，变更的字段将不会被跟踪。

参考链接：

>