从零打造通用游戏服务器----开篇、目录

开篇

随着go语言学习的深入，包括实际中自己的需求，决定从头实现一套自己的微服务架构的游戏服务器。其中会融入很多我对于微服务的理解，以及对于整体架构设计思想的表达。
全部文章不涉及到具体的代码实现，只包含结构设计、程序设计、表设计、缓存设计，力求按照文中内容无论使用任何语言均能快速搭建出设计的服务。

我理解的微服务

按照我对于微服务的理解，微服务应该符合的标准：

1. 独立性 ，一个服务提供一个功能。例如日志服务，只提供将请求的数据写入到日志文件中。
2. 通用性，服务提供的功能能尽可能的支持各类需求。依然拿日志服务举例，日志有很多种格式化方式，那么这些差异内容交给服务调用方去决定，日志服务只提供将调用方请求的字符串写入到日志中。
3. 扩展性，现代的互联网公司越来越看重大数据下的服务器表现，以及如果一开始没有做好对大规模请求的处理，后面再来进行重构将是非常痛苦的一件事情。因此最好能实现水平扩展。
4. 平衡性，最理想话的服务，是只提供一个单一的服务，如果有其他需求，则通过调用另一个提供该服务的服务来解决。但是服务越多，耦合越大，越不利于维护，因此服务的功能与独立要充分考虑权衡。

服务列表

1. 用户服务器
2. 逻辑服务器
3. 排行榜服务器
4. 邮件服务器
5. 日志服务器
6. 战斗服务器
7. web服务器
8. 聊天服务器

通用功能

为了使服务更加具有适用性，以及尽量避免需要依赖额外的服务才能跑通整个流程。对于很多中小公司来说，不管是用户量还是服务压力都还远远达不到需要使用集群的地步，那么最好的方式其实是服务本身自带的功能足够完善，不需要很多额外的服务，相信谁也不喜欢为了使用一个服务而装一大堆软件来支撑。
因此，我们的全部服务提供以下几点公共的特性：

1. 全部接口均提供以protobuf为协议的tcp连接方式以及以json为载体的http连接方式。
2. 全部服务均自带一个简单的存活接口（类似心跳检测），可方便用户开发简单的服务管理工具。
3. 全部服务均自带一个自身服务基本信息的接口，例如使用了多少个go程，如果内部带全局常驻内存的list这种，还可以显示出占用了多少内存等。方便用户管理。
4. 全部服务均保证上层使用一个简单的负载均衡，则可以实现服务的横向扩展。
5. 存储使用DB、缓存使用redis，缓存redis不涉及数据的永久存储，只做缓存使用，全部需要永久存储的数据必须落库。保证做到如果没有redis，全部服务也可以正常运行。（工作中经常碰到有为了性能，有些数据直接存redis中的情况，这种情况最终可能会对数据管理、迁移上带来很大不必要的麻烦，为了性能，完全可以弄一个定时脚本之类的专门进行redis数据落库工作）

服务流程

---