【记录】一次项目架构的设计

基本情况说明：

我学校开设的《软件开发环境与工具》是以项目为导向的，本次实验虽然是用 Visio制作软件项目中相应的图形，但是难点不在于Visio的使用，而是项目思想的一种体现。

团队成员有五人，在原型设计(实验2)之前已经完成 API文档的编写，本次实验3是结合2描述整个系统的数据流和架构等。

因为本人作为组长要上台展示，故文档不涉及细节具体的描述（担心上台讲解回和念文档差不多）

本次的实验，也是对我们从3月份接触Java八个月以来的一种检验。

下面即为正文内容，好的地方，共同学习；不足之处，欢迎拍砖。

---

码上运动

一、产品概述

随着互联网市场的快速发展，程序员这一行业越发受到追捧，然而，程序员们将大部分的时间精力都投入到了事业上，却忽视了自身的身体健康，而“码上运动”的出发点就是为程序员团体打造一款专属的运动app。

通过更贴近程序员视角的ui设计以及功能全面的运动模块，让程序员们从此不只爱代码，更加爱运动，目前市场上主流的运动app都没有明确的受众定位，尤其没有仅针对程序员团体开发的运动软件，作为互联网时代技术浪潮中的“弄潮儿”，程序员们更多的时间都是以代码为伴，忽视运动从某种意义上就是忽视健康。

因此，“码上运动”以新颖的设计理念将程序员与运动的主体结合起来，创造性地实现板块设计，在保证运动功能模块完整实现的同时，增加更多贴合码农们喜好的设计元素，让码农们感到亲切关怀的同时，在这款专属于程序员团体的运动app上码不停蹄地码上运动！

「码上运动」是一款程序员圈具有社交属性的健身APP

二、UI设计及功能

（1）登录部分

主要分为手机号登陆和第三方登陆，因为面对程序员，所以我们增加了github的登录方式.

（2）运动功能

分为跑步，行走，骑行，瑜伽，放松和拉伸

（3）社区功能

分为长发及腰，我型我塑，颈椎挺住，码农装备，极客时间，立个flag。以及搜索，发布等功能

（4）消息功能

可接受私人消息，和社区的通知消息

（5）个人中心及设置功能

包括勋章功能，运动数据，个人资料等等

三、项目流程图

程序流程图、数据流图、业务流程图、网络略

下面介绍项目流程图

四、项目数据流图

五、项目系统架构图

下面展示的是系统架构图：

技术选型与系统架构设计

（1）前端部分

作为曾经炙手可热的Android工程师，现在面临着以下的问题：

1. 互联网整体环境不乐观
2. Android开发人员众多但岗位减少，导致要求越来越苛刻
3. 大前端趋势、跨平台方案频出、小程序肆虐，Android不再是应用开发唯一的方案
4. 几年前Android火爆的时候，培训机构倾巢出动，学校学生疯狂学习。社会中输送了大量Android开发的人，导致培训Android出来就失业，大学学Android出来大多也失业。

因安卓实验，老师亲自命题，故这里果断舍弃安卓。

---

团队具备条件：

1. 五人均有前端开发经验
2. 其中有一个人对前端开发非常熟悉

综合团队的技术点，选择跨平台解决方案uni-app

uni-app，目前是最终极的跨平台框架。因为

1. 跨的平台更多（Android、iOS、小程序、H5）
2. 性能体验更好（小程序技术框架和weex加持）
3. 三方扩展生态更丰富， 即支持小程序sdk又支持原生sdk，大部分sdk厂商都有小程序sdk，也就是大部分sdk都可以直接用于uni-app的扩展生态，而且是原SDK厂商来维护。这意味着uni-app拥有了所有跨平台方案中最丰富的三方生态。开发者不用找原生工程师去封装环信、网易云信等im的原生sdk了，直接用他们的小程序sdk即可。
4. 开发方式更现代： vue数据绑定、npm、webpack、各种预处理器 公有技术，学习成本更低
5. 掌握uni-app需要学习的是vue的语法，小程序的api，学会这些是理所应当，并不为uni-app额外增加学习成本。

uni-app也有限制，但综合看仍然是最好的跨平台开发方案。

(2) 后端部分

团队具备的条件：

1. 团队有六台服务器可用
2. 三人都有微服务相关的经验。

技术选型：

• 开发框架： Springboot
• 服务框架：Dubbo
• 注册中心：Zookeeper
• 反向代理：Nginx
• 第三方依赖管理工具：Maven
• 工具框架：Guns
• 分布式数据库系统 ： Mycat
• 数据库：Mysql
• 容器部署：Docker
• 容器的集群管理平台：kubernetes (简称k8s)

2.1 服务集群

后端向前端提供的功能以微服务的形式进行展现，用以实现高可用。

为了服务的可拓展性，Dubbo提供了注册中心，新增的服务要在Dubbo中进行注册（采用dubbo协议），Dubbo协议之间的通信是长连接。

2.2 API网关

服务聚合主要就是发现服务，这个也需要用到Zookeeper，为了发挥分布式的优势，自然而然选择异步调用。

权限控制采用RBAC的设计，敏感数据采用 MD5加盐 进行加密，采用传统的JSON WEB TOKEN（JWT）鉴权方式

遗憾和不足之处在于无法实现高性能最重要的一块地方–分布式缓存（一般使用Redis），原因是组中没人能驾驭得了。但是我们给出的解决方案是 使用本地缓存（热点数据 LRU）以及服务的负载均衡 还有并发控制。

为了避免高并发下，服务雪崩等以及赢得更好的用户体验，我们采取的负载均衡策略是 最少活跃调用数 以及 服务熔断、服务降级 和 服务限流（令牌桶算法）。

最后就是服务分组和分组聚合了，这是一种处理数据库分表的一种策略。

2.3 FTP服务器

可替代：对象存储Object Storage Service （OSS）

2.4 数据库集群

Mycat是一个超级数据库代理，一种高可用中间件。

2.5 Nginx集群

web应用服务器。

2.6 CDN

考虑CDN的加速

2.7 部署

Docker +K8S