第十三期技术夜校分享嘉宾是——小夏
他曾独立负责得物第一版交易系统和供应链系统
经历了交易业务从0到1的整个过程
主导了第一次交易系统迁移至Java
带领团队完成社区业务迁移至Golang
导语
社区是得物App最早时期的业务，从最开始做资讯为用户提供各种潮流相关一线资讯信息，到现在各种花式的内容形态如图文、长图文、短视频、直播等，社区逐渐变得丰富起来，对社区的一些技术也造成了一定的压力与挑战。因此为了迎接更大的流量到来，我们针对社区业务进行了微服务化改造，让我们的技术架构更加的清晰并且能够承接更大的流量。
此次技术夜校小夏为大家介绍了社区的业务、单体技术以及微服务化改造的整个过程，帮助大家更加深入了解社区的业务及技术架构情况。
业务发展阶段
得物社区在这5年内主要经历了以下几个阶段：
15年上线初期只有资讯，主要提供一些Sneaker资讯类信息，由富文本内容类型来承载；到16年新增了对UGC的支持，用户可以自主发布内容，用户可以发布的内容主要包含了以图片为主的图文类消息和图文混合的富文本类的专栏；随后17年增加了达人问答，主要是提供平台为用户和达人开通一个沟通渠道，用户可以直接通过问答的方式与达人进行交流；19年开始推广短视频及直播等丰富了社区的内容形态，包括新增一些内容审核，过滤掉一些不符合平台调性的内容，同时已经开始有一些业内KOL及明星开始入驻得物社区。
经历过5年的发展迭代后，目前社区业务上的主要内容形态有以下几种，其中图文和短视频是占比较大的比重的，富文本类型的内容如资讯和专栏已经相对较少，专栏主要用来输出一些更加专业性的物品测评以及平台运营活动的工具。
在这五年的发展中，除了内容形态逐步变多，业务的体量也是在飞速增长的，从0到1，再从1到W日活。
早期技术架构演进
得物早期的技术和常规互联网公司基本一样，使用PHP技术栈，阿里云等云服务商作为基础设施的支撑，常用的一些中间件如M有SQ、Redis、ES等，最早时期使用Redis来作为MQ和缓存使用，但比较容易出现MQ的消息丢失和Redis节点被拖垮的情况，后来引入RocketMQ来保证消息的稳定性及Redis自身的稳定性，技术栈整体成本相对较低，架构相对简单，迭代速度也比较快。
在业务快速增长的过程中，社区的技术架构也有比较大的变化。从业务早期，体量较小的时候一直都是单机单应用在运行，所有的业务在一个应用系统里面，包括社区、鉴别、交易等，这种情况大概到10W日活的时候有一些瓶颈了，于是在应用层做了拆分和负载均衡，解决了当时的痛点问题。但随着业务的不断迭代及业务规模的的不断增加，业务耦合导致故障频发、效率低下，于是根据大的业务域做了数据库的垂直拆分，拆分为社区、鉴别、交易等，应用层还是只有一个应用系统，但也从服务器的维度去拆分为社区机器、鉴别机器、交易机器等，降低一定的耦合性。
痛点问题
即使做了很多架构上的调整，但是所有业务在一个系统里面始终还是会有比较多的痛点问题。社区业务已经经历了5年多的迭代变更，遗留了很多技术债需要解决，下面从几个维度剖析一下社区业务的的主要痛点问题：
1、业务抽象设计不足
社区现在在内容形态上分为动态、专栏、资讯、问答等，每种内容形态都是独立的数据表，在接口层面不同的内容形态数据结构也不尽相同，非常不利于维护及与客户端的对接，沟通成本比较大，效率也无法提升，一个变更影响多个内容形态的话需要重复的开发；在内容的评论上面也是一样的问题，动态、专栏、资讯、问答各自有各自的评论表，数据结构及分表规则也不一致，需要比较多的时间才能了解的全面；社区很多入口场景都是各式各样的内容聚合流页面，目前的流页面的结构也各不相同，同样产生过各种各样的对接问题。
2、项目过大职责不清
单个系统项目经过长期迭代，代码仓库已经有2G，代码量过大且有很多历史债务，框架是早期自研的一个简单的MVC框架，分层不够清晰，逻辑复用过多且依赖过深，底层一个改动会影响巨大的面，所有开发人员维护同一个项目，职责权限无法控制，业务边界不好划分。
3.性能及稳定性不足
PHP版本过低，加上项目过大导致升级比较困难，语言自身的一些局限性，并发能力差，本身不支持连接池等技术，很难抗住社区业务特性的突发性流量；目前也很难支持像样的限流、熔断等技术，相关生态不如Java、Go等静态语言；PHP框架早期自研时未考虑太多安全相关的事项，扩展版本也比较古老，漏洞问题频繁发生但升级又困难。
4、部署及链路复杂
按业务拆分多个服务器，但是项目还是同一个导致部署状况复杂，早期接口没有一定的规范，导致分流规则复杂，运维成本巨大，尤其在扩容的时候，需要同步更新所有的规则到新的机器上，研发同学也很难了解所有的细节情况，导致线上产生问题时，定位问题的速度被降低。
微服务化改造
得物的社区业务正在飞速发展，未来一年肯定会达到一个新的量级，在这个节点到来前，我们必须要解决现有的这些问题。既要能够提升研发效率保证业务快速迭代的同时，又要能够保证系统的性能及稳定性。研发团队也越来越大，我们需要能够按组去专注在各自的业务上，而不是全家桶式迭代，提升研发同学的职责，划分清晰业务边界。在部署层面也希望能够清晰明了，降低维护成本。
服务拆分梳理
得物社区的核心业务模块主要分为Feed流、内容、互动以及用户。
?Feed流就是常见的内容聚合页面，得物的Feed流场景特别多，有推荐主页、推荐频道页、