创新小课堂项目设计总结及思考

| 导语 产品背景：糖大夫是服务于 糖尿病患者的，我们之前有了糖大夫智能血糖仪测量收集用户数据，有了糖大夫公众号让用户能够及时了解亲属病情，同时丰富了积分兑换，设备购买等配套服务。已有的这些功能对于慢性病患者来说可能还不够， 如果能够对这类糖友进行糖尿病医疗知识普及教育，让他们能够更好的了解饮食，运动，生活作息，用药控制等知识，对于糖友们来说可能是更需要的，有了这些我们产品的粘性和价值会很好。所以，糖大夫公众号内多了随身课堂这样一个关键的菜单。小课堂针对糖尿病人上线后效果很好，现在已经复制到小儿哮喘继续试点，后续将陆续扩展到更多病种，让小课堂服务更多需要普及医疗知识的人群。 本文主要介绍小课堂已有系统架构设计及后续支持接入更多合作伙伴，扩展多病种，多合作商的一些思考。

抽象小课堂的业务需求大方向来说主要是医疗教育内容供给，内容是核心，平台作为内容生产者提供有价值的医疗知识，用户作为消费者来定课学习从而带来了有价值的消费者行为信息。小课堂不仅做知识传授，还会收集用户当前病情，行为习惯等个人信息更好的帮助医疗机构了解患者从而提供更精准的治疗。

为了避免小课堂像医疗百科一样枯燥的文章讲解，产品们要求课程内容是趣味知识问答形式，图文，音频并茂，增加了课后闯关，个人成就，勋章点亮等，丰富了平台的趣味性，为了更好的帮助用户进行行为约束我们还增加了任务模块，用户可以领取任务，执行任务，让用户通过行为实践来更好的控制病情。用户还可以通过知识等级测验来评估自己各个维度的知识水平，然后根据评估结果的专家建议继续在小课堂里学习来补齐短板，丰富知识。用户还可以预约感兴趣的课程，要求我们提供更需要课程内容。

另外，小课堂合作的医疗机构有多家，提供的内容可能不同。针对合作医疗结构的用户我们要求能够识别身份渠道，做到渠道隔离，提供对应渠道内的内容。

大概总结一下需求逻辑图：

输出的课程是已章节为单位的，一个章节就是一门课程的专题，里面会分几个小节课程从不同角度讲解，我们所说用户定课最小单元是章节，课程的层级结构：

用户定了一门课就是定了这个章节，完成这门课的学习，就是顺序学习章节内的多节，每一节课程内会有多个知识点，同一个知识点会有多种场景的讲解方式，让用户更好理解。完成小节课程学习后要参加课后闯关，评估自己的学习成果，帮助用户更好的了解自身知识掌握情况，用户还可以对课程进行打分评价，帮助我们提供更高质量的课程内容。

有了这样的需求背景，我们怎么来设计系统呢？

首先设计这样的系统都需要满足哪些需求，做哪些准备：

1.内容型平台首先要满足内容更新上架的需求，生产方需要一个运营系统来管理内容。

2.用户使用场景各种功能满足需求的同时，尽量避免模块间关联，提高系统可扩展性。

3.永远的不变就是需求一直在变，所以系统要考虑产品变更方向，预留更大的可变空间，抽象层次要提高。

4.系统尽量提高可复用性，公共模块尽量独立，个性化场景需求通过冗余数据的形式来进行关联，避免重复工作量。

5. 完整的系统需要有完善的监控体系，监控数据变化，分析系统性能，保证系统稳定运行。

6. 任何系统都需要进行业务数据统计，根据业务数据结果分析产品形态及用户喜好。

7. 思考系统容灾方案，保证数据安全。

带着这样一些设计思路，看下我们现在的系统结构：

逻辑层内部结构：

1.我们提供了小课堂运营系统，所有的内容录入都有产品通过运营界面操作完成，自助化灵活运营，避免研发人力的消耗。

2.系统在设计的时候考虑了模块化流程，我整体总结为以下几块：选课上课相关流程模块，实践任务相关流程模块，等级测评相关流程模块，个人中心信息汇总模块，对外合作渠道管理模块，消息触达及其他公共模块等，方便后续代码管理及配套资源的模块化管理。

3.课程等公共资源作为基础内容独立于任何个性化合作方内容之外，额外通过课程与渠道管理的冗余方式来实现个性化需求，满足各种渠道变化需求。

4.公共资源的独立提高了复用性，渠道化管理和公共资源结合可以提高各渠道个性化需求支持的灵活性。

5.代码逻辑层按模块化开发相对解耦，保证系统后续的业务可扩展性。

6.标准taf化接口，系统流量及性能统计全图形化监控，随时可以监控流量变化及系统性能压力。

7.利用show平台提供了简单的业务数据统计，数据层面都有一主两备的安全保护，保证数据安全。

系统部署图：

部署层面：

服务模块都是docker化部署，流量会经过负载均衡到达各个服务器，运维平台会根据docker的负载情况自动扩容和缩减机器，保证资源有效利用及业务稳定运行。

不足及后续需要思考的方向：

1.现有系统逻辑分层可以再细化，由于之前人力和时间的限制，代码分层化存在不足。

2.业务量增长带来性能压力，需缓存数据增多，根据业务需求组织缓存数据，满足性能要求。

3.满足更高的系统稳定性及高可用性，可以引入分区互备方案，业务量增大后，同一合作方可能需要多区的服务来支持，服务分区部署支持各个地区的业务量，相同的业务可以互相作为备份，保证个别地域机房后者网络出现问题的情况下业务正常可用。

如下图：

4.渠道化管理需抽象度更高，由于合作方会越来越多，合作方内部可能还会再做细分，同时还存在单合作方管理多病种的可能性，对系统的复杂度提出了更大的挑战，对于数据模型如何组织提出了更高的要求。

思考用户数据可以这样组织：

病种编码+合作商编码+合作商业务区域ID+用户id  

通过多维度数据来支持多合作商，多病种，多地域的数据形式，另外继续保证基础数据的独立性和公共复用性，通过合作方信息和基础信息的关联冗余数据来管理。

创新项目都是在摸索中前行，需求不断变化，方向不断调整，系统难免存在一些不足，优化之路永无止境，表面上举重若轻，压力和辛苦置身其中才会明白，只希望团队的付出能得到更多用户的认可，希望小课堂能够越走越远。