본명 우이 숨겨진 남자는, 구안 지안 장, 10 년 이제 게임 경력, 해변 은둔입니다.
이 튜토리얼로 이동 언어 파티션 게임 서버 프레임 워크는 예를 구축합니다.
이동 프로그래밍 언어 가비지 컬렉션 기능으로 구글이 개발, 컴파일, 헤어 정적 강력한 형식의 언어입니다. 대략 C 언어의 문법 객체 지향 유산을 포함하는 다른 컨셉 구조체 구조체 방식으로, 인터페이스를 지원한다. C / C ++에 비해 C / C ++에 비해 성능, 동시 프로그램을 개발하는 것이 더 강력하고 더 쉽습니다. 나는 이동에 노출 된 후, 더 이동에 의해 개발 된 게임 서버를 수행하는 경, C ++ 서버를 작성하는 데 사용.
소위 파티션 게임, 게임을 말합니다이 영역의 번호로 구분되며, 플레이어는하지 상호 작용 또는 서로 다른 영역 사이의 작은 상호 작용을 할 수 있습니다. 플레이어는 게임에 파티션을 지정, 파티션을 선택하는 게임 필요를 입력, 플레이어는 다른 파티션에 역할을 할 수 있습니다. 현재 시장에서 가장 심각한 온라인 게임은 카드, MMORPG, SLG 등등과 같은 대화 형 게임에 대한 큰 DAU 게임을 필요로하지 않는 구역 설정,이 모델을 채택했습니다. 기술적 인 수준에서 클러스터 확장의 수단 파티션, 작업이 파티션 미세 사업자에 도움이되는, 서비스 사업자가되었습니다 압연 추가 게임 운영자 수단을 성숙이다. 상대 파티션 게임, 소셜 게임의 칸막이가없는,이 게임은 같은 COC와 같은 핵심 게임 플레이에 대해 일치합니다. 존 지정 지구 게임, 서비스 노드의 클래스의 게임지도, 방송 서비스가 옷에 맞게 매핑 된 경우, 게임의 파티션의 구조는 잘 이해되지 않습니다.
이 튜토리얼은 게임 서버 파티션 프레임 구조에 대해 주로. 다음과 같이 전체적인 디자인은 다음과 같습니다
파티션 게임은 플레이어가 처음 게임에 로그인 한 다음 지정된 파티션을 입력합니다. 그래서 우선은 로그인 서버가의 글로벌 로그인 서비스를 제공합니다. 플레이어 계정이 핵심 데이터 서버입니다 로그인, 핵심 사업은 자신의-계정 시스템, 타사 계정 로그인의 사용을 포함, 검사에 로그온 할 수있는 선수이다. 데이터 요구의 계정 장기 보관은 이렇게 플레이어의 계정 정보를 보유하고있는 서버에 MySQL 데이터베이스를 지원하고, 가을. 게임에 로그인 검증 여러 로그인 프로세스에 대한 서비스가있다. 로그 서비스는 Nginx에 의한 외부 주소로 통합 액세스, 서비스 프로세스 로그인 다중로드 밸런싱을 제공, HTTP 프로토콜을 사용하여, 짧은 연결 서비스입니다. 일반적으로, 인터페이스는 파티션 로그인 정보로 돌아갑니다, 역할 플레이어 각 파티션에 대한 간략한 정보, 고객 번호의 최신 버전, 구성 버전, 버전 리소스, 공지 사항 및 기타 정보는 응답 옷 로그인, GM 서빙 동적 업데이트에 의해 (나중에 소개합니다) 할 수있다 취득 및 요청에 따라 클라이언트에 반환. 그래서 데이터를 캐싱을위한 레디 스 서비스를 지원하는 서버에 로그인합니다.
플레이어의 성공은 게임에 로그인 한 후, 게임은 선택한 파티션을 입력합니다. 구역 설정은 서비스 프로세스의 집합입니다. 작은 게임 마이크로 채널, 웹 소켓을 사용하는 것을 고려 계정에 지금 인기 H5 게임을 복용하면 대부분의 게임은, 긴 분할 통신 연결을 사용하는 것은 통신 (이전에 사용 된 소켓을) 할. 계정에 게임의 요구를 복용 방송, 방송 데이터 및 게임 데이터 파티션이 클라이언트에 동일한 연결에서 복귀 기대하고있을 것, 그것은 통합 서비스 파티션 진입 게이트웨이를 제공 할 필요가있다, 게이트웨이 서버는 클라이언트의 조닝과 주소의 통합 과정을 제공합니다 포트는 내부 데이터 전달을 수행. 논리 파티션 서비스는 과정에서 하나 개의 서비스 게임에 집중 할 수 있습니다. 게임 데이터는 MySQL을 자주 읽고, 너무 자주 변경되기 때문에 이전 게임 중 일부는 온라인 게임 서비스 데이터, 프로세스의 메모리에 저장됩니다 및 쓰기 성능은 MySQL로 저장할 때마다 전에 약간의 시간이 될 것 높지 않다. 하위 지역하지만游戏服是一个单点，一旦崩掉，游戏服的内存数据就会丢失，回档到上一次保存的时间。后来一些游戏为了减少这种风险，把在线数据保存到共享内存，再定时保存到MySQL。共享内存依赖系统和语言，目前发现Go没有直接支持。再后来有了memcached和redis，部分游戏选择用这种缓存系统做缓存，游戏服崩掉，数据还在缓存里不会丢失，可以快速启动游戏服恢复服务。我选用redis作为缓存，缓存活跃玩家数据。隔一定时间，把变化数据保存到MySQL。redis数据主要使用key-value方式保存数据，每次业务处理都需要读取、解析，再使用。对业务开发不是很友好。游戏服进程内存还是会保存在线玩家数据，玩家进入分区时从redis读取到游戏服内存，redis不命中则发布消息给数据服进行数据预热，预热成功后从redis读取。后面的请求可以直接通过内存数据做业务判断、处理，更改数据以事务方式保存到redis，成功后响应给客户端。这样内存数据跟redis数据一致，而且可以把玩家数据拆成更细的单元，减少跟redis间的通信。玩家下线后清除游戏服内存数据。所以分区内配套一个redis、一个MySQL。为了建立定时保存数据这个机制，且不会因游戏服崩溃而受影响，配备一个功能很简单的数据服，通过redis的发布订阅机制、消息队列，负责数据的定时落地固化、玩家注册、数据预热。
前面提到广播服，广播服顾名思义主要负责广播，例如跑马灯广播、世界聊天、世界boss。广播服通过各个分区的网关服将数据广播给玩家，因此广播服将连接各个分区网关。广播任务通过消息队列进行缓存，这样每个分区的广播操作在写到队列后就可以响应客户端。消息队列采用redis实现。广播服是一个全局的服务，为了避免单点风险，可以做成主从，通过redis的订阅发布机制，启动时订阅redis，如果一定时间没有收到发布消息，认为主服务不存在，切换为主服务，取消消息订阅，连接各分区网关，定时向redis发布消息报活。
除了业务相关的服务，需要对整个服务体系提供管理。例如开服、停服、更新配置/资源版本、发邮件、发公告、发放道具、踢人等。提供一个全局的gm服，各分区服务启动后，游戏服进程连接到gm服并保持心跳，以通知gm服开/停服。gm服将这些变更信息更新到登录服的redis，这样玩家登录游戏就知道各个服的状态。gm服还可以通过向redis发消息通知登录服进行封号等操作。由于各个游戏服都连接到gm服，这样就可以对各个分区发gm命令。gm服可以通过向广播服的消息队列写消息发全员广播。gm服的功能由运营人员进行操作，所以需要提供http服务，方便在网页上访问。gm服有道具发放的功能，所以第三方支付回调可以通过gm服的http接口请求发货。
为了给运营提供决策，还需要提供统计后台，对游戏数据日志进行收集、统计。由于登录服、各分区的游戏服、gm服都会上报数据，数据来源广，数据量大，需要做消息队列。因此登录服、游戏服、gm服都通过redis的消息队列进行上报。统计服从redis读取消息，保存数据日志到MySQL。因此需要配套一个redis、一个MySQL。统计服的功能由运营人员使用，需要提供http服务，方便在网页上访问。统计服的http接口还支持客户端进行数据上报。
为了合并运营人员的页面，gm服、统计服通过nginx提供统一的http地址。
这样就得到了如前面设计图的整个服务框架。
本篇介绍到这里，接下来会详细介绍各个服务的实现。在此之前，下一篇先介绍一些通用的基础机制设计和实现。