• 贫血模型即事务脚本模式

• 充血模型即领域模型模式

贫血模型

最早广泛应用源于EJB2，最强盛时期则是由Spring创造，把

• “行为”（逻辑、过程）

• “状态”（数据，对应到语言就是对象成员变量）

分离到不同的对象中：

• 只有状态的对象就是所谓的“贫血对象”（常称为VO——Value Object）

• 只有行为的对象就是我们常见的N层结构中的Logic/Service/Manager层（对应到EJB2中的Stateless Session Bean）。（曾经Spring的作者Rod Johnson也承认，Spring不过是在沿袭EJB2时代的“事务脚本”，也就是面向过程编程）

贫血领域模型是一个存在已久的反模式，目前仍有许多拥趸者。Martin Fowler曾经和Eric Evans聊天谈到它时，都觉得这个模型似乎越来越流行了。作为领域模型的推广者，他们觉得这不是一件好事。

贫血领域模型的基本特征是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。对象之间有着丰富的连接方式，和真正的领域模型非常相似。但当你检视这些对象的行为时，会发现它们基本上没有任何行为，仅仅是一堆getter/setter。其实这些对象在设计之初就被定义为只能包含数据，不能加入领域逻辑。这些逻辑要全部写入一组叫Service的对象中。这些Service构建在领域模型之上，使用这些模型来传递数据。

这种反模式的恐怖之处在于，它完全和面向对象设计背道而驰。面向对象设计主张将数据和行为绑定在一起，而贫血领域模型则更像是一种面向过程设计，Martin Fowler和Eric在Smalltalk时就极力反对这种做法。更糟糕的时，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。

如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。贫血领域模型的根本问题在于，它引入了领域模型设计的所有成本，却没有带来任何好处。最主要的成本是将对象映射到数据库中，从而产生了一个O/R（对象关系）映射层。只有当你充分使用了面向对象设计来组织复杂的业务逻辑后，这一成本才能够被抵消。如果将所有行为都写入到Service对象，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处。正如martin在企业应用架构模式一书中说到的，领域模型并不一定是最好的工具。

将行为放入领域模型，这点和分层设计（领域层、持久化层、展现层等）并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。如果你要讨论能否将数据源或展现逻辑放入到领域模型中，这就不在本文论述范围之内了。

一些面向对象专家的观点有时会让人产生疑惑，他们认为的确应该有一个面向过程的服务层。但是，这并不意味着领域模型就不应该包含行为。事实上，service层需要和一组富含行为的领域模型结合使用。

Eric Evans的Domain Driven Design一书中提到：

• 应用层（即Service层）

描述应用程序所要做的工作，并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑，或和其它项目的应用层做交互。这层很薄，不包含任何业务规则或知识，仅用于调度和派发任务给下一层的领域模型。这层没有业务状态，但可以为用户或程序提供任务状态。

• 领域层（或者叫模型层）

表示业务逻辑、业务场景和规则。该层次会控制和使用业务状态，即使这些状态最终会交由持久化层来存储。总之，该层是软件核心。

服务层很薄——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点：如今人们常犯的错误是不愿花时间将业务逻辑放到合适的领域模型中，从而逐渐形成面向过程的程序设计。

我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型，特别是那些以数据为中心的开发人员。此外，有些技术也会推动这种反模式，比如J2EE的Entity Bean，这会让我更倾向于使用POJO领域模型。

总之，如果你将大部分行为都放置在服务层，那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层，那你就无可救药了。

优点

简单

• 对于只有少量业务逻辑的应用来说，使用起来非常自然

• 开发迅速，易于理解

• 注意：也不能完全排斥这种方式

缺点

无法良好的应对复杂逻辑

• 比如收入确认规则发生变化，例如在4月1号之前签订的合同要使用某规则…..

• 和欧洲签订的合同使用另外一个规则…..

充血模型

面向对象设计的本质：“一个对象是拥有状态和行为的”，比如一个人：

• 他眼睛什么样鼻子什么样这就是状态

• 人可以去打游戏或是写程序，这就是行为

为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢？举个简单的J2EE案例，设计一个与用户（User）相关功能。传统的设计一般是：

• 类：User+UserManager

• 保存用户调用：userManager.save(User user)

充血的设计则可能会是：

• 类：User

• 保存用户调用：user.save()

• User有一个行为是：保存它自己

其实它们没有什么特别适用的方向，个人更倾向于总是使用充血模型，因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。因此实际工程场景中，是否使用，如何使用还依赖于设计者以及团队充血模型设计的理解和把握，因为现在绝大多数J2EE开发者都受贫血模型影响非常深。另外，实际工程场景中使用充血模型还会碰到很多很多细节问题，其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。

如果一个对象包含其他对象，那就将职责继续委托下去，由具体的 POJO 执行业务逻辑，将策略模式更加细粒度，而不是写 ifelse。

从一个问题说起

五年前发现分页场景下，mysql请求速度非常慢。数据量只有10w的情况下，select xx from 单机大概2，3秒。我就问我导师为什么，他反问“索引场景，mysql中获得第n大的数，时间复杂度是多少？”

答案的追寻

确认场景

假设status上面有索引。select * from table where status = xx limit 10 offset 10000。会非常慢。数据量不大的情况就有几秒延迟。

小白作答

瞎猜了个log(N)，心想找一个节点不就是log(N)。自然而然，导师让我自己去研究。

这一阶段，用了10分钟。

继续解答

仔细分析一下，会发现通过索引去找很别扭。因为你不知道前100个数在左子树和右子数的分布情况，所以其是无法利用二叉树的查找特性。通过学习，了解到mysql的索引是b+树。

看了这个图，就豁然开朗了。可以直接通过叶子节点组成的链表，以o(n)的复杂度找到第100大的树。但是即使是o(n)，也不至于慢得令人发指，是否还有原因。

这一阶段，主要是通过网上查资料，断断续续用了10天。

系统学习

这里推荐两本书，一本《MySQL技术内幕 InnoDB存储引擎》，通过他可以对InnoDB的实现机制，如mvcc，索引实现，文件存储会有更深理解。

第二本是《高性能MySQL》，这本书从着手使用层面，但讲得比较深入，而且提到了很多设计的思路。

两本书相结合，反复领会，mysql就勉强能登堂入室了。

这里有两个关键概念：

• 聚簇索引：包含主键索引和对应的实际数据，索引的叶子节点就是数据节点

• 辅助索引：可以理解为二级节点，其叶子节点还是索引节点，包含了主键id。

即使前10000个会扔掉，mysql也会通过二级索引上的主键id,去聚簇索引上查一遍数据，这可是10000次随机io，自然慢成哈士奇。这里可能会提出疑问，为什么会有这种行为，这是和mysql的分层有关系，limit offset 只能作用于引擎层返回的结果集。换句话说，引擎层也很无辜，他并不知道这10000个是要扔掉的。以下是mysql分层示意图，可以看到，引擎层和server层，实际是分开的。

直到此时，大概明白了慢的原因。这一阶段，用了一年。

触类旁通

此时工作已经3年了，也开始看一些源码。在看完etcd之后，看了些tidb的源码。无论哪种数据库，其实一条语句的查询，是由逻辑算子组成。

逻辑算子介绍 在写具体的优化规则之前，先简单介绍查询计划里面的一些逻辑算子。

• DataSource 这个就是数据源，也就是表，select * from t 里面的 t。

• Selection 选择，例如 select xxx from t where xx = 5 里面的 where 过滤条件。

• Projection 投影， select c from t 里面的取 c 列是投影操作。

• Join 连接， select xx from t1, t2 where t1.c = t2.c 就是把 t1 t2 两个表做 Join。

选择，投影，连接（简称 SPJ） 是最基本的算子。其中 Join 有内连接，左外右外连接等多种连接方式。

select b from t1, t2 where t1.c = t2.c and t1.a > 5 变成逻辑查询计划之后，t1 t2 对应的 DataSource，负责将数据捞上来。上面接个 Join 算子，将两个表的结果按 t1.c = t2.c连接，再按 t1.a > 5 做一个 Selection 过滤，最后将 b 列投影。下图是未经优化的表示：

所以说不是mysql不想把limit, offset传递给引擎层，而是因为划分了逻辑算子，所以导致无法直到具体算子包含了多少符合条件的数据。

怎么解决

《高性能MySQL》提到了两种方案

方案一

根据业务实际需求，看能否替换为下一页，上一页的功能，特别在ios, android端，以前那种完全的分页是不常见的。这里是说，把limit, offset，替换为>辅助索引（即搜索条件）id的方式。该id再调用时，需要返回给前端。

方案二

正面刚。这里介绍一个概念：索引覆盖：当辅助索引查询的数据，只有id和辅助索引本身，那么就不必再去查聚簇索引。

思路如下：`select xxx,xxx from in (select id from table where second_index = xxx limit 10 offset 10000)“ 这句话是说，先从条件查询中，查找数据对应的数据库唯一id值，因为主键在辅助索引上就有，所以不用回归到聚簇索引的磁盘去拉取。再通过这些已经被limit出来的10个主键id，去查询聚簇索引。这样只会十次随机io。在业务确实需要用分页的情况下，使用该方案可以大幅度提高性能。通常能满足性能要求。

你听说过OpenJDK，但是你听说过OpenValueJDK吗？近日一家来自欧洲、从事Java生态的全栈软件公司OpenValue准备干一件大事。他们受到一个叫Bluebonnet[1]的开源项目的启发（一个在.NET平台部分实现的JVM），打算开发一个新的 JDK,这个 JDK 将同时支持 Java 和.NET 字节码！这就是OpenValueJDK。说干就干，目前OpenValueJDK 官方网站[2]已经放出来了，但是更多的细节还没放出来。

OpenValueJDK

OpenValue放言他们计划于明年 4 月 1 日发布第一版。现在大公司都在玩跨语言的全栈JVM，Oracle 刚刚推出了 GraalVM，现在又来一个OpenValueJDK，JVM生态越来越热闹了。

Java 和 .NET 曾经是水火不容的两套生态系统，它们都可以用于构建软件、网站和 Web 应用程序。Java程序员和.NET程序员曾经因为谁更好争的“死去活来”。

但是由于Java可以可以运行在任何一种操作系统之上，经过 25 的发展已经构建了一个无可比拟的生态体系。而.NET则走了和Java相反的路子，虽然微软也开始认识到开源和跨平台的重要性，但是为时已晚，.NET生态和Java生态已经不可同日而语。

我很期待明年 4 月 1 日的OpenValueJDK，嗯 4 月 1 日发布!

一直关注DD的朋友应该还记得，今年年初时Elastic公司曾宣布改变其名下的开源协议，而对此AWS（Amazon Web Services——Amazon云服务）就随即表示自己将在仍为开源状态的 Elasticsearch 和 Kibana（ 7.10 版本）创建分支，今后自己来维护这个分支，做到真正的开源。

转眼间已经过了快三个月，当初的这个真正的开源事件就在近日有了下文。

4月12号，AWS官方宣布推出 OpenSearch 项目！

根据AWS的官方介绍，OpenSearch 项目由OpenSearch和OpenSearch Dashboards组成，这两项的确也都是基于当初所说的Elasticsearch 和 Kibana（ 7.10.2 版本）。

项目均采用Apache License 2.0 开源许可协议，功能完成度也不少，包括像企业安全、告警、机器学习、SQL、索引状态管理等，应有尽有。

而针对Elasticsearch之前的改变以及自己的真开源讲法，AWS表示OpenSearch虽然时基于Elasticsearch，但是删除了其中和Elastic有关的商业许可证限制、代码、商标等，在采用了Apache License 2.0 之后，OpenSearch可以让每个用户都毫无负担的构建和创新，而不用再担心一些贡献之外的问题。

同时，AWS还宣布现有的 Amazon Elasticsearch Service，将会变更名号，成为一个崭新的Amazon OpenSearch Service！

更名之后的Amazon OpenSearch Service，想必是为了摆脱和Elasticsearch的关联，在不影响正在运营业务的前提下，还会提供一系列可供部署和运行的开源引擎，包括当前可用的 19 个版本的 Elasticsearch（7.9 和更早版本、近期推出的 7.10）以及新版本的 OpenSearch。

为了满足现有用户的使用需要，AWS还宣布未来的Amazon OpenSearch Service API 将与现有服务 API 完美兼容，还会为用户提供将现有 Elasticsearch 6.x 和 7.x 托管集群迁移至 OpenSearch 的无缝升级路径。

可能在未来的几周内，我们就能见到AWS发布 Beta 版本，根据AWS的展望，预计在2021年中期发布稳定版并投入生产环境使用。

随着AWS的声明，不少公司都纷纷站队表示支持，像红帽、SAP、Capital One 和 Logz.io 都是其坚定的盟友。

红帽表示：

我们感谢亚马逊对开放搜索的承诺，我们很高兴看到亚马逊继续支持开源

SAP表示：

SAP客户期望一个统一的、以业务为中心的、开放的SAP业务技术平台。OpenSearch提供了一个真正的开源途径和社区驱动的方法来推动这一进程。

Capital One说到：

我们非常支持OpenSearch项目，因为它将使我们能够更好地控制和自主选择数据平台，同时保留开放源代码许可证提供的自由。

而第一个站出来吐槽Elastic公司的Logz.io则发言：

我们承诺与AWS和社区其他成员合作，创新并使世界各地的每个组织都能享受这些关键的开源项目带来的好处。

那到底AWS的OpenSearch能不能达到大家的预期呢？我们拭目以待！

由全球领先的互联网通信云服务商融云主办的 Geek Online 2020 编程挑战赛，于 2020 年 10 月 17 日举办了线上总决赛。本届大赛以“后疫情时代通信云技术的创新及实践”为主题，以融云 IM 和 RTC 的 SDK 为编程项目，历经近两个月的激烈角逐，15 支队伍在近百份参赛作品中突出重围，闯入总决赛，最终决出冠亚季团队及四个单项奖。

入围作品主要集中于社交、游戏和工具等多个类别，为鼓励开发者挖掘创意、实现更多实时音视频和即时通讯技术的应用场景，最终，评委根据作品完整性、项目创意性和潜在商业价值三个维度进行综合评分，与数百万在线观众一道，见证了冠军队伍的诞生。

团队：赚钱养家

作品：Script Game

源码地址：https://github.com/rongcloud-community/RongCloud_Hackathon_2020/pull/46/files

• Script Game的是一款线上剧本杀APP，它为喜欢剧本和推理的用户提供一个游戏平台。剧本杀是一种注重推理的互动桌面游戏，也是现代青年聚会的常玩娱乐之一。

• 进入APP的玩家，可以选择不同的剧本，按照游戏流程轮流发言、使用道具，最终完成自己的目的、找到真正的凶手，而凶手则要隐藏自己，嫁祸他人。 在剧本杀中用户将作为一部故事中的角色，可以是侦探推理真凶，可以是古人恩爱情仇，浪荡天涯，可以是现代人心冷暖，在所扮演的角色中，体验到另一种人生。

• 在Script Game 这个开放包容的APP中，用户可以体验不同的故事，也可以与不同的人们一起扮演不同的角色。

目录

• APP功能及使用介绍

• 用到的技术

APP功能及使用介绍

1.剧本杀房间

• 用户可以选择是否成为一个主持人（组织者）的身份，并且进行剧本杀流程的把控。

• 每次游戏开始存在人数限制，超出限制的用户可以选择等待或者旁观。

2.剧本选择

• 不同房间有不同的剧本，用户根据自己想法选择封闭式玩法或者开放式玩法

3.创建剧本

• 用户可以根据自己需求创建剧本，并且建立房间，成为房间的管理者。

用到的技术

• 融云 SDK

• IMKit

• RCTLib

• Android JetPack

• LifeCycles

• DataBinding

• LiveData

• Navigation

• ViewModel

• WorkManager

• Retrofit

• OkHttp

• Glide

• EventBus

• 本程序实现方案及技术主要自参考融云官网https://www.rongcloud.cn/

由全球领先的互联网通信云服务商融云主办的 Geek Online 2020 编程挑战赛，于 2020 年 10 月 17 日举办了线上总决赛。本届大赛以“后疫情时代通信云技术的创新及实践”为主题，以融云 IM 和 RTC 的 SDK 为编程项目，历经近两个月的激烈角逐，15 支队伍在近百份参赛作品中突出重围，闯入总决赛，最终决出冠亚季团队及四个单项奖。

入围作品主要集中于社交、游戏和工具等多个类别，为鼓励开发者挖掘创意、实现更多实时音视频和即时通讯技术的应用场景，最终，评委根据作品完整性、项目创意性和潜在商业价值三个维度进行综合评分，与数百万在线观众一道，见证了冠军队伍的诞生。

团队：生活不易

作品：Sing Together

源码地址https://github.com/rongcloud-community/RongCloud_Hackathon_2020/pull/23/files

• Sing Together 为各位音乐爱好者提供一个共同K歌的机会。

• 在这里每个人都可以是“蒙面歌王”，共同体会音乐的魅力，为自己喜欢的歌声打call。

目录

• APP功能及使用介绍

• 用到的技术

APP功能及使用介绍

1.K歌室

• 进入K歌室以后，就可以进行在线K歌功能，在线进行音乐风暴狂欢。用户可选身份有：

• 主持人

• 普通K歌

• 听众

2.粉丝互动

• Sing Together的平台支持一位主播与多名粉丝的互动活动，粉丝可以为主播点赞、赠送礼物。

3.在线交友

• 在K歌室中，每个用户之间可以进行互动，通过互动来增加彼此交流。

用到的技术

• 融云 SDK

• IMKit

• RCTLib

• Android JetPack

• LifeCycles

• DataBinding

• LiveData

• Navigation

• ViewModel

• WorkManager

• Retrofit

• OkHttp

• Glide

• EventBus

• 本程序实现方案及技术主要自参考融云官网https://www.rongcloud.cn/

由全球领先的互联网通信云服务商融云主办的 Geek Online 2020 编程挑战赛，于 2020 年 10 月 17 日举办了线上总决赛。本届大赛以“后疫情时代通信云技术的创新及实践”为主题，以融云 IM 和 RTC 的 SDK 为编程项目，历经近两个月的激烈角逐，15 支队伍在近百份参赛作品中突出重围，闯入总决赛，最终决出冠亚季团队及四个单项奖。

入围作品主要集中于社交、游戏和工具等多个类别，为鼓励开发者挖掘创意、实现更多实时音视频和即时通讯技术的应用场景，最终，评委根据作品完整性、项目创意性和潜在商业价值三个维度进行综合评分，与数百万在线观众一道，见证了冠军队伍的诞生。

团队：曈塔天线

作品：Warm Heart

源码地址https://github.com/rongcloud-community/RongCloud_Hackathon_2020/pull/26/files

• WarmHeart的开发目标是为人们提供一个情感碰撞平台，人们可以在这里分享自己的喜怒哀乐。在遭受挫折和迷茫时，能够通过WarmHart的暖心室获得他人的温暖和指导。

• 随着生活节奏的加快，现代人的压力增大，而WarmHeart的主要目标之一是发挥语言的力量，为人们提供心理慰藉。

• 在WarmHeart可以遇见温暖的普通陌生人，也可以找到专业的情感大师。在每个暖心室里面，都会常驻一位心理咨询师作为主持人，在分享经验的同时还能帮助人们解决心理问题。

• 本程序为Warm Heart的Andriod版本。

目录

• APP功能及使用介绍

• 用到的技术

APP功能及使用介绍

1.通过手机号注册用户

• 用户通过手机号，获取验证码即可登录，开启旅程。 

• 
  

2.暖心畅聊室

• 这是大家进行交心的地方，由主持人控制房间的情况，每个房间有除主持人外有8个发言位置。

• 聊天社交

• 互送礼物

• 心理咨询

• 个人分享

• 更多功能可自行挖掘 

• 
  

3.发布新话题

• 如果对当前的畅聊室不满意，可以自主新建新的畅聊室。

用到的技术

• 融云 SDK

• IMKit

• RCTLib

• Android JetPack

• LifeCycles

• DataBinding

• LiveData

• Navigation

• ViewModel

• WorkManager

• Retrofit

• OkHttp

• Glide

• EventBus

• 本程序实现方案及技术主要自参考融云官网https://www.rongcloud.cn/

由全球领先的互联网通信云服务商融云主办的 Geek Online 2020 编程挑战赛，于 2020 年 10 月 17 日举办了线上总决赛。本届大赛以“后疫情时代通信云技术的创新及实践”为主题，以融云 IM 和 RTC 的 SDK 为编程项目，历经近两个月的激烈角逐，15 支队伍在近百份参赛作品中突出重围，闯入总决赛，最终决出冠亚季团队及四个单项奖。

入围作品主要集中于社交、游戏和工具等多个类别，为鼓励开发者挖掘创意、实现更多实时音视频和即时通讯技术的应用场景，最终，评委根据作品完整性、项目创意性和潜在商业价值三个维度进行综合评分，与数百万在线观众一道，见证了冠军队伍的诞生。

团队：NCC_621

作品：Werewolf

源码地址https://github.com/rongcloud-community/RongCloud_Hackathon_2020/pull/24/files

• Werewolf的开发目标是为人们提供一个在线狼人杀游戏平台。

• 在Werewolf中，玩家可以在线开始狼人杀游戏，每个玩家都会被分配到一个身份，每个身份都起到不同的作用。

• 游戏分为两大阵营：狼人阵营和好人阵营。而胜利条件有多种：所有狼人出局，好人胜利；所有好人出局（屠城）狼人胜利以及所有平民出局或所有神职出局（屠边）狼人胜利。。

• 在Werewolf中玩家可以自由选择游戏对象，还可以围观他人的游戏过程，体验推理和社交的快乐。

目录

• APP功能及使用介绍

• 用到的技术

APP功能及使用介绍

1.通过手机号注册用户

-用户通过手机号，获取验证码即可登录，开始游戏。

2.游戏房间

• 用户进入房间之后，游戏由房间中担任上帝的玩家控制过程，其他成员有各自不同的身份。 --每一局狼人杀游戏都将从夜晚开始，每一个夜晚狼人可以睁眼并共同猎杀场上的一位玩家。夜晚之后将会进入白天，白天是所有玩家发言和投票的环节。 --每个白天场上存活的玩家将按顺序依次进行发言，在所有玩家发言结束后，法官将会组织一次放逐公投，在放逐公投中每一位玩家都拥有一票的投票权，玩家可以选择把票投给自己心目中所认为的狼人。最终，得票数最多的玩家将会被放逐出局并留下“遗言”。 --“遗言”之后游戏将会进入下一个夜晚，狼人又可以再一次睁眼选择一位玩家进行猎杀，如此“黑夜—白天—黑夜”循环，直到某一方阵营达成了胜利条件，则游戏结束。

• 玩家可以在房间中进行游戏，也可以旁观他人的游戏，也可以创建自己的游戏房间。

用到的技术

• 融云 SDK

• IMKit

• RCTLib

• Android JetPack

• LifeCycles

• DataBinding

• LiveData

• Navigation

• ViewModel

• WorkManager

• Retrofit

• OkHttp

• Glide

• EventBus

• 本程序实现方案及技术主要自参考融云官网https://www.rongcloud.cn/

由全球领先的互联网通信云服务商融云主办的 Geek Online 2020 编程挑战赛，于 2020 年 10 月 17 日举办了线上总决赛。本届大赛以“后疫情时代通信云技术的创新及实践”为主题，以融云 IM 和 RTC 的 SDK 为编程项目，历经近两个月的激烈角逐，15 支队伍在近百份参赛作品中突出重围，闯入总决赛，最终决出冠亚季团队及四个单项奖。

入围作品主要集中于社交、游戏和工具等多个类别，为鼓励开发者挖掘创意、实现更多实时音视频和即时通讯技术的应用场景，最终，评委根据作品完整性、项目创意性和潜在商业价值三个维度进行综合评分，与数百万在线观众一道，见证了冠军队伍的诞生。

团队：芮爸&芮妈

作品：芮爸&芮妈

源码地址

https://github.com/rongcloud-community/RongCloud_Hackathon_2020/pull/45/files

一、服务端：

云端地址http://h.363z6.top/admin

开发的时候使用使用google chrome浏览器的，还没有考虑兼容问题，请尽量使用google chrome浏览器打开

用户名：admin 密码：123456

1、服务端是采用python的tornado框架来搭建的，数据库使用的mongodb

2、在服务端上安装了融云python-server-sdk可以直接调用

3、修改融云server-sdk的app_key和app_secret在libs/rongcloud/RongCloudBase.py 里面修改

4、修改mongodb的连接信息在libs/db/mongodb.py里修改

5、服务端的模块分为两大块 admin 和 int

admin是主要管理用户和消息，是使用了easyui作为前端框架，在admin模块中可以实现一对多的聊天功能。

主要是满足在网页环境中客服人员对咨询者进行一对一的即时聊天对话

int 主要是面向client提供api支持

二、客户端

1、客户端是直接使用h5页面写的，前端框架是使用了bootstrap再结合vue和jquery，在本地可直接运行也可放到互联网环境中

2、客户端中调用了融云的web-sdk

3、客户端调用的API是由服务器的int模块提供的

4、目前是完成了单聊功能，输入用户名密码后初始化后选择需要进行聊天的用户进行对话即可

5、在index.html中修改APPKEY中的值即可，root_url是服务器的地址

以下为几个测试账号

用户名: huang 密码: 123456

用户名: huang1 密码: 123456

用户名: huang2 密码: 123456

用户名: admin 密码: 123456

由全球领先的互联网通信云服务商融云主办的 Geek Online 2020 编程挑战赛，于 2020 年 10 月 17 日举办了线上总决赛。本届大赛以“后疫情时代通信云技术的创新及实践”为主题，以融云 IM 和 RTC 的 SDK 为编程项目，历经近两个月的激烈角逐，15 支队伍在近百份参赛作品中突出重围，闯入总决赛，最终决出冠亚季团队及四个单项奖。

入围作品主要集中于社交、游戏和工具等多个类别，为鼓励开发者挖掘创意、实现更多实时音视频和即时通讯技术的应用场景，最终，评委根据作品完整性、项目创意性和潜在商业价值三个维度进行综合评分，与数百万在线观众一道，见证了冠军队伍的诞生。

MaxFloat 是一支有实力，有梦想，有创意，敢拼搏，即想即做的队伍。他们认为当前城市化生活环境下人与人的交流越来越少，宠物逐渐替代朋友成为更好的伙伴，养宠物的越来越多，但随之而来的是更多的问题，比如宠物的遗失、被抛弃造成了流浪宠物越来越多，而宠物的健康，有时也不能及时得到重视。因此他们做了一款以宠物招领、寄养、寻回、宠物医生等为主，以宠物信息普及、宠物疾病普及为辅的 APP 帮助广大宠物爱好者。

团队：MaxFloat

作品：宠宝儿

源码地址

https://github.com/rongcloud-community/RongCloud_Hackathon_2020/pull/7

开发技术

•服务端：java，maven+SpringMVC，layui， mysql，h5，js，css，jsp 

•客户端：Swift+OC，cocoapod，RongIMKit， RtcLib

功能简介 

1，⽤户信息模块，登录，注册，修改

2，宠物信息模块，常⻅宠物，热⻔宠物 

3，宠物资讯，常识，公告模块

4，宠物救助模块，招领，寻回，领养 

5，宠物医⽣模块 

6，IM单聊模块 

7，低延迟直播模块 

8，分享模块

直播功能：

 • 1，⼩窗⼝模式，⽤户可以缩⼩当前直播⻚⾯，并且可以拖动，进⽽可以进 ⾏其它操作 

• 2，静⾳，切换视频采集源 

• 3，消息列表，直播过程中，⽤户可发送消息，使⽤聊天室功能 

• 4，主播端可查看当前观看直播⼈员 

• 5，⽤户端可送礼物给主播 

• 6，魅⼒值，每⼀个礼物都附带特定的魅⼒值，礼物可以提升主播的魅⼒值 

• 7，直播界⾯展示主播头像，昵称，当前观看⼈数，魅⼒值等，后期接⼊其它相关功能

后期功能规划 

1，完善现有功能，救助模块，宠物医⽣模块和直播模块 

2，宠物寄养模块 

3，宠物疾病模块 

4，短视频模块与直播模块功能结合 

5，计划对接宠物医院和救助站与宠物医⽣相结合 

6，计划开发宠物商城模块，与宠物医院，直播模块相结合