微服务架构选型实战-优快云博客

本文链接：https://blog.youkuaiyun.com/u014084297/article/details/118282268

架构选什么主要从以下两点考虑。

第一点，最重要的一点，是其他所有的基础。有没有在有限时间内hold的住将要用的技术。

第二点。你的业务什么样的，你的需求是什么。需求影响了：数据量，并发量，响应时间，可用性。

基于以上两个关键点，本项目选用了spring cloud全家桶为主要核心的微服务架构。

核心架构，一号位大哥的选择

接下来就说根据两点分别进行阐述。

就我个人而言：擅长java服务器方面。最擅长的是游戏，但是web也有把握压得住。只要是java后端我都有绝对的把握，因此本次技术选择只要在java的大语言环境内就行了。另外我对java的常用配套系统，因为我已经主导过上线的项目了，所以也都可以解决。

反之，例如：我也会一些unity c#，比如本项目的前后端网络长链接通讯，逻辑部分我解决了大部分，但是一旦到了显示层面，我就不想搞了。

另外还有一个好处，这门语言或者技术会的人多不多，业内有没有比较好的相关规范。java目前是人数最多的几门语言之一。业内规范也非常明确：《阿里巴巴开发手册》。ps：貌似我还可以写一篇：读《阿里巴巴开发手册》有感。

考虑到本城市的大环境，会crud的程序员比专门的游戏程序员要多。招人快速扩展也要容易些。这点传统滚服架构输了一招，当然这不是致命伤。致命伤在下边。

没有业务谈架构全是耍流氓，这句话的另一种说法就是：一切的架构要根据对业务的适用性来做。

本次技术选型将传统滚服架构战胜的原因是：这个项目是全球同服的休闲游戏。全球同服，休闲。两个关键字的联合出击彻底将传统滚服的刷帧方式送归天堂。

全球同服就意味着：数据量和并发量有极高的概率是一个服务器无法承受的。而放到不同步服务对于有状态的游戏服务器来说，互相间的高频通讯又是一个噩梦。对于微服务架构而言，这些是基本微服务的基本业务。在传统滚服架构里，这些都是致命的弱点。微服务已经重拳出击，那对微服务的弱点。滚服又如何反制呢。

滚服游戏，最大的优点是什么，就是快，微服务的响应500毫秒就算可以接受了。在刷帧滚服里，我们可以做到20毫秒的常规响应，要求再高我们个位数毫秒响应时间都是平平常常，甚至常规状态下的不到1毫秒做出响应。但是休闲，对于我们的响应时间其实没太高要求。200毫秒都是可以接受的。这对于微服务来说也是可以轻松达到的数值。至此滚服架构彻底失去反击手段。被微服务架构“恩赐解脱”。

架构风格，拆分规则，管理规则。2号位的选择。

这个位置最为重要。也是整个项目中最自由，难度最高的部分。一个人的代码能力90%的都体现在这个位置。

架构统筹了各个系统，大局观很重要，就是取舍和安全性的规则保证。

需求方案怎么确定，简单的实现可能扩展性很差，扩展性好的可能又麻烦些。

快速实现，单点结构可用性和水平扩展就可能要差些。分布式实现又比较的慢。

这个插件用不用，用了有什么好处，有什么坏处。

这个功能如何抽象拆分，或者是和其他功能类似要合并。

策划或者产品经理要的到底是什么，什么东西可以和他们商量，进行调整修改。

什么东西底层实现逻辑是一套，但是实现的功能是另外一回事。

项目拆分，哪些功能要拆到一个项目。

微服务理论上要全部拆分。但是全拆了，占的内存就大了。用的服务器就多了，能不能申请下来。就是既让马儿跑，又让马儿少吃草。而且全拆了，开发成本也会上升这能不能接受。

运行速度有多少，对响应时间要求多少，对安全性要求多少，是不是使用的内存和cpu必须要好的。数据库存数据多久能接受。

拆分的项目比实际运行的项目要多，这些功能拆分成一个项目，有没有必要性。

这些问题都是平常遇到的常规问题，还有一堆稀奇古怪的问题，比如线上的某个功能不能用了，但是开发环境没事，数据库连接失败了。

到某个时间数据落地极易失败。

这些问题全部需要这里去解决。

这没法细写，东西太多了。

这些能力综合起来，才构成了这个位置的negligible表。

数据传输：3号位

后端本质是什么：对数据的移动处理呈现

数据传输就是数据的移动。

在逻辑层数据是对象，向客户端传输时又是双方都接受的协议，在向数据层传输时，数据又变成了字节码、sql。

这里单讨论向客户端的协议和连接选择。

我们的需求中明确有要求，聊天功能，公告推送能。所以这里用http短链接是不合适的。我在此次选用了，游戏常见的netty加protobuf结构。netty是公认的稳定好用长链接框架。protobuf是速度和大小均为极佳的序列化框架。另外这两个我用起来比较顺手了。json相对来说速度和包体大小都要差得多。

这里常见的坑有：分包粘包问题，序列化封装问题，大小端问题，序列化前后端不一致问题。