1 实践 教育公司下业务框架

背景：公司为初创型教育公司。以获客转化作为公司的主要营收途径。用户增长周期为标准AARRR模型。

C端产品主要分为：APP，WX，官网，移动端H5

后端网关：根据业务框架，分为四个网关及业务对接门户。分别为app-service, wx-service, web-service, portal-service(内部系统门户)。为什么分为四个门户呢？优点：1各C端产品带有不同的客户端属性，便于对各端数据流进行分析。如APP会带有操作系统，设备信息等，后续可以通过这些信息对用户分层，如IOS，ANDROID用户群的消费转化等。2各C端产品的业务推广等业务不同。如：APP可以对设备进行push消息进行流失用户召回等。

服务层：由于各业务模块间及相互交互的复杂性。怎样合理有条理地相互调用，是我们在架构设计的难点。我们通过对开源框架及公司业务的梳理，以中台思想把功能模块分为 业务功能模块和基础服务模块。模块间可以平行和向下调用，禁止向上调用。如模考模块可以调用单词模块，可以盗用题库模块，题库模块不能调用模块模块。若必须调用，可以通过mq等实现。另外，为了进一步拆解模块间的关系。各模块把实体和应用拆解，分为两个项目：**-service,**-entity。模块间可以依赖**-entity。

         服务通信，http调用，可以满足公司绝大多数要求。因此使用spring-web下的restTemplate调用，熔断机制为公司自研框架。暂时没有实现其他RPC框架。在此，强调下直播现使用第三方直播服务支持用户上课，数据通过第三方API获取。但随着业务的不断扩展，第三方直播服务支持的功能越来越不能满足业务需求，在其服务上继续使用还是在某些PASS基础上自研就是个艰难选择。

         基础服务组件, 我们抽取为包含各层基类，基础异常及状态码，工具类等不依赖第三方插件的common-base,和依赖第三方插件的common-support。

 资源层：主要工作为选型和灾备。选型不做赘述。灾备目前主要用阿里云服务和异地灾备等。