架构解密从分布式到微服务：架构实践，身边购平台实践

身边购平台实践

“身边购”是一种有效的销售模式，特别是在日常生活、个体户服务(含零工)及闲置物品交易等领域。笔者曾在2018年的Java高端培训系列课程Spring篇的大作业中提出打造“身边购”平台的构思，致力于打造一个开源的、公益性质的互联网平台产品，协助社区中的各类店铺、个体户、自由职业者及社区居民零成本上网自助交易，促进以社区为核心的低碳、环保的健康生活。

这里就以打造“身边购”平台为例，开始我们的“架构解密”之旅。

首先，我们来分析并准确描述这个系统所涉及的角色，如下图所示。

其中，对各个角色的定位如下。

●社区用户:在平台，上选购物品或者交换、出售自己的闲置物品。

●附近商家:在平台上发布商品及服务，接受附近用户的订购。

●服务提供者: 附近的技能型人才可以在平台上发布自己可提供的服务,兼职或全职均可，常见服务包括快递、跑腿、修锁开锁、水电维修、钟点工、杂工、保洁等。

●平台志愿者:负责核实平台中的一- 些关键信息，例如商家信息、各类服务提供者的身份信息，并协调解决平台中交易引发的纠纷等。

下面是系统的主要用例图。

软件设计是一门介于工程与艺术之间的手艺活，一个杰出的架构师一定是脑洞大开的，而在整个软件工程过程中，最能引发设计灵感并挑战我们的架构设计能力的是一开始的产品设计。

以“身边购”平台来说，虽然从总体来看它是个小型的针对性的电商系统，只有一个比较特殊的关键因素一邻里距离， 但如何以这个核心因素为出发点，设计出一个完全与众不同的购物平台，则是对我们创新能力的一个考验。如下图所示就是笔者设计的身边购App的主界面。在第一眼看到这个界面时，你有什么样的想法?

首先，将用户以其所处地理位置为中心划一个圆， 在圆的直径覆盖范围内的商家和服务提供者才符合入选条件。于是我们看到一个有趣的现象:用户从城市的一个点移动到另外一个点，无须搜索，身边“圈子”的商家信息会被自动推送到视野之内，用户可以直观、快速地从周围的商圈获取便捷服务。这就是身边购App的核心思想。设想一下， 用户在周末打算出游到同城某个比较远的地方，又不想错过途中一些好玩好吃的地方时，还可以让平台为其在沿途自动选择几个落脚点，甚至往返路线不同;并且，在给出这些落脚点的同时，平台会自动为其推荐周边的公交、餐饮、娱乐、景点，甚至预订相关商品和服务。如果该平台模拟探险类手游界面，将购物完全融入游戏中，未来再增加街景和VR功能，就是完全融合游戏、社交、购物体验为一体的全新平台，是完全以用户为中心的设计思想的体现。

继续回到我们的设计中来，要实现上述目标，需要解决以下一些关键的技术问题。

如果你觉得自己学习效率低，缺乏正确的指导，可以加入资源丰富，学习氛围浓厚的技术圈一起学习交流吧！
[Java架构群]
群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的JAVA交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。

首先，对身边购App中的每个店铺(含服务提供者)都需要标记地理坐标，使用者的位置信息很关键，需要快速查询出以使用者当前位置为中心的指定半径内的实体对象，并且在界面中渲染出来。查找半径范围内的对象属于空间搜索技术里的一种，目前主流的数据库通过空间索引的方式也都提供了查询语句，Redis 提供的Geo模块则另辟蹊径，结合其有序队列zset以及geohash编码，实现了极高效率的空间搜索功能，因此可能的一个设计思路是一种组合模式: 用Redis实现商铺的地理坐标存储，用MySQL数据库实现商铺的详细信息存储，如下图所示。

地图中的店铺及标注物还会有一些动态信息， 部分动态信息关联到当前用户的消费行为,对这部分信息的深度挖掘和关联分析可以用到某些AI技术。随着身边购App用户群体的规模越来越大，收集的数据越来越多，AI 会变得越来越重要。这里撇开AI不谈，只谈店铺相关的动态信息的存储和推送问题。考虑到动态信息具有时效性、不变性及总体量大的特点，适合将其单独放到以某种磁盘存储为主的NoSQL存储系统中。

另外，考虑到有大量的用户、店铺及信息要展示，如何展示、缓存也都是这个系统要解决的关键问题。就信息展示来说，我们可以考虑采用多重技术手段来展示信息。

●以“分层”方式展示地图上的信息，按照重要程度，先展示基本信息，再一层层叠加其他信息。

●部分数据以 “有关注才亮”的方式拉取和展示，即在有用户单击店铺的某个提示时客户端才去服务器.上拉取数据。

●客户端是一个手机App, 因此手机端可以缓存大量数据，这是一个优势:将常用的、变动频率小的甚至短时间内(几个小时内)基本不会变的信息数据尽可能缓存下来，例如商店的图标、缩略图、基本信息(含位置)，甚至用户常用的几个区域如住所、公司、常去场所附近的地图等，通过有效利用客户端的缓存，可减少服务端的交互，提升客户端UI的灵敏度和用户体验。

●客户端的后台线程提前拉取数据，在获得完整数据后再刷新和展示界面。

●采用客户端的后台线程定时更新某些时效性相关的数据。

这样做有几个好处:首先，可以增加用户界面的反应灵敏度;其次，在很大程度上降低了整个系统拉取或推送数据的压力，在节省资源和带宽的同时提升系统的并发支撑能力。App和Server端可以采用主动下推与客户端主动拉取数据这两种模式。在这个系统中建议主要以客户端主动拉取数据的模式为主，采用某种合适的RPC通信方式，包括基于HTTP 2的gRPC都是可行的方案。对数据接口的设计可以考虑如下技巧。

●将数据版本化。对可变数据特别是传输代价大的数据，尽可能带版本标签。相关接口可以参照HTTP,增加返回结果码，比如200表示正常返回数据对象，其他状态码则有特定含义，比如301表示此数据已经是最新版本，无须再获取，这样就在不增加调用次数的同时，减少了不必要的网络传输。

●增加批量传输接口。在考虑接口响应时间的前提下增加批量传输接口，以提升平台的传输效率。注意，这里不是简单的分页批量，而是可以让客户端指定-批目标对象进行批量传输。

●将全量接口与增量通知接口相结合。其中,全量接口用于客户端一次性拉取全部对象数据，然后客户端注册增量通知接口，当相关的目标对象发生变化(增删改)时，服务端主动通知客户端，客户端再高效同步本地缓存的全量数据。在Kubernetes 集群及Istio这种新的分布式集群中，这是一种常 见的做法。该做法在编程方面增加了复杂度，很考验架构师和研发人员的实力,但对于集群规模的提升及响应时间的缩减效果明显。此时，可选Zokeeper. Eted 系列的特殊NoSQL存储，因为它们自带异步通知机制，是全量+增量通知接口机制的最佳搭档，如果有兴趣，则可以研读Kubernetes API Server中的相应代码并参考和实现。

如下所示是比较完整的App与Server端的架构示意图。

在这个系统中还存在一类特殊的实体对象，即“地图”，这是因为实体商圈、居民聚集区、办公聚集区通常是大部分人高频汇聚并逗留时间比较长的场所，把这些区域做成地图并在Server端提前计算出地图里包含的各种信息数据，当某个人来到或者要查看这个区域的信息时，客户端App很快就能展现相关界面了，可大大提升用户体验。类似地，针对每个用户的行程习惯，我们也可以设计用户个性化的地图并在App本地缓存起来。平台还可以根据统计信息，自动创建和维护区域内的热点地图，将其加入缓存并自动淘汰非热点地图，以节省内存。

至此，系统的主要实体对象关系如下图所示。

最后，我们需要考虑的是如何推广这个项目?有两种思路:一种是先给出PPT再去找机构投资，创立公司、全职创业;另一种是IT人合伙兼职共享创业，个人承担的风险小、容易坚持到胜利，也是成功后收益最大的一种模式。具体思路如下。

先寻找适合此项目开发的有创业想法的IT人才，注册成立一个创业公司，主要以参与项目开发的方式入股，其中部分有资金实力的股东又可追加少量的资金作为公司的流动资金。考虑到部分人可能无法坚持到项目上线，可以考虑合适的退出机制，比如在平台未来有收入的情况下予以工作量的现金补偿。如果启动资金充足,则也可以考虑雇佣部分全职IT人员以加快研发。采用这种共享创业模式，如果在武汉等二线城市的共享办公空间办公并招募当地的一两名初级软件工程师，则公司的启动资金可能20万元足够，平摊到5个股东，人均4万元即可开启稳妥的共享创业之路。在共享创业模式下，前期的研发、上线后的IT运维等相关主要工作都以技术派股东为核心，少招募员工，尽可能节省公司的流动资金。

这个产品的可能收入包括如下几部分。

●店家:店铺年费、发布广告的费用、打赏。

●用户:打赏、VIP客户的特效费用，类似于QQ的收费。

平台上线后的运营和推广（主要地推）需要大量人手，此时可以考虑社会零工加志愿者的用工模式，在每个区域都征集一些零工和志愿者负责线下推广，加入的店家越多，店家和用户的满意度越高，打赏也多，可以考虑将大部分打赏作为对线下运营推广人员的奖励，鼓励他们持续做好服务。而在线上前期可能只招募一个全职客服即可满足需求，整体人力成本的控制做到量入为出，不求速度，只求稳定，用两三年打好基础。在做到团队能自己养活自己的前提下，再去寻求外界资本，整个团队就有更大的话语权，公司的估值也就越高，在未来资本推动上市后，获取的回报也越大。

写在最后

最近我整理了整套《JAVA核心知识点总结》，说实话，作为一 名 Java 程序员，不论你需不需要面试都应该好好看下这份资料。拿到手总是不亏的~我的不少粉丝也因此拿到腾讯字节快手offer，点击下面图片↓直达领取

好了，以上就是本文的全部内容了，如果觉得有收获，记得三连，我们下期再见。