移动端眼里的后端开发

一、分工

1、原始社会

当大自然的第一批原始人在大自然中（真正的荒野求生），为了生存选择群居抱团，为了遮风挡雨躲避猛兽住进山洞。有些原始人跑得快胆子大就去追逐打猎，有些人跑得慢就去开荒种地，有些原始人喜欢发明创造就打造石器，有些原始人心灵手巧就编制树叶衣服...

2、社会大分工

马克思认为产生分工的本质是生产力不断发展的结果。

恩格斯在《家庭、私有制和国家的起源》一书中提出的发生在东大陆原始社会后期的三次社会大分工，即游牧部落从其余的野蛮人群中分离出来；手工业和农业的分离；商人阶级的出现。

3、技术大分工

随着互联网的发展，以开发语言或平台为划分标准的技术分工也越来越细，演变出多种技术栈。

前端开发：Html、Css、Js、React、Vue等

移动端开发：Android、iOS、React Native、Flutter等

后端开发：Java、C++、PHP、Go、Python、数据采集、音视频开发等。

二、后端

笔者做了多年的iOS，本以为可以一劳永逸，还是太是想的太简单了。

计划总赶不上变化，活到老学到老是不变的真理，拒绝给自己设限。

去年在项目中没有iOS大的需求，也正好之前对后端开发比较好奇，就转做后端Java开发一年。

从开始的接口Crud（增删改查），一个接口开发，一个模块的开发到一个完整项目的整体开发、部署、发版、上线、跟踪、迭代的全流程参与。

一个移动开发眼中的Java服务端开发不就是给客户端提供接口么？

说的没错！但不止如此！

除了提供接口外，还有其他工作

1、服务部署（把Jar包部署到测试、线上不同的机器上，这不是运维做的事么）

申请机器、申请lvs、申请域名（自己按照公司流程申请配置）

Nginx负载均衡部署（类似路由分发到不同的机器上，配置Web启动页）

服务迁移、数据库迁移、数据库合并（这不是DB要做的事么）

2、数据清洗（一年内整理合并过几千个Excel，这tm不是大数据工程师做的是事么）

数据库的数据导入导出（导入清洗好的Excel或导出Pm要的统计数据）

3、应急响应（如果业务或机器挂了，半夜也会起来改，这时候才体会到做客户端的快乐）

4、编写技术架构、数据库设计等文档（为了iSO9001标准或政府/企业政府项目的验收文档）

5、架构抽象（研究最适合的架构，分子化业务，调研不同的框架或工具）

6、安全过审（同一IP限制、请求次数限制、Https证书等）

7、考虑高并发引发的系列问题（这是日活月活量大的产品需要考虑的）...

举个栗子：

就像移动端开发一个登录功能，根据PM、UI、UE的设计做出界面，只需要输入用户名和密码，然后等待响应结果。

从不用考虑登录频率限制，IP限制，验证码是否有效，密码是否匹配，登录会话如何保持，安全防刷等。

移动端只需要关心你调用Api的Http Status 是否为200。

后端的逻辑还是比较复杂的，有一些成熟的框架可以满足大部分场景。

前端的追求：界面美观惊艳、页面交互流畅、业务逻辑清晰、组件化合理、对外sdk稳定等。

后端的追求：接口稳定、架构合理、业务逻辑清晰、模块拆分合理、支持高并发等。

三、历程

下列是Java企业级项目开发中的不同架构模式。一年不长，但以下几种架构模式都接触参与过。

1、JSP（前后端混合开发）

JSP全称Java Server Pages，是一种动态网页开发技术。它使用JSP标签在HTML网页中插入Java代码。标签通常以<%开头以%>结束。

JSP是一种Java servlet，主要用于实现Java web应用程序的用户界面部分。网页开发者们通过结合HTML代码、XHTML代码、XML元素以及嵌入JSP操作和命令来编写JSP。
复制代码

JSP通过网页表单获取用户输入数据、访问数据库及其他数据源，然后动态地创建网页。

JSP标签有多种功能，比如访问数据库、记录用户选择信息、访问JavaBeans组件等，还可以在不同的网页中传递控制信息和共享信息。

2、Spring Boot （后端独立的单体服务）

SpringBoot是由Pivotal团队在2013年开始研发、2014年4月发布第一个版本的全新开源的轻量级框架。它基于Spring4.0设计，不仅继承了Spring框架原有的优秀特性，而且还通过简化配置来进一步简化了Spring应用的整个搭建和开发过程。另外SpringBoot通过集成大量的框架使得依赖包的版本冲突，以及引用的不稳定性等问题得到了很好的解决。

其设计目的是用来简化新Spring应用的初始以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。简而言之，Spring Boot通过提供默认配置的方式整合了所有的框架，让我们可以更加简单、快速、方便地构建应用程序。

3、Spring Cloud （微服务）

微服务是一种架构风格，即将单体应用划分为小型的服务单元，微服务之间使用 HTTP 的 API 进行资源访问与操作。这一点和SOA很类似。

微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务。微服务不再强调传统SOA架构里面比较重的ESB企业服务总线。微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。相比SOA而言，微服务的切分粒度会更小。

所以，微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。

4、Spring Cloud Alibaba（阿里微服务）

Spring Cloud Alibaba 是阿里巴巴提供的微服务开发一站式解决方案，是阿里巴巴开源中间件与 Spring Cloud 体系的融合。

阿里开源组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

四、工程

查看相关对应历程的项目工程代码如下...

五、矛盾

同为产品服务，后端和前端相互依存，也难免有一些相爱相杀的矛盾。

1、没有文档

可以使用Swagger或Mook，若有修改，及时更新并同步。

2、文档不全

建议这样

{
     code : 0/ 1/ 2/ 3,  // 0代表正常，1是参数有误，2是用户不存在，3是用户没权限等
     msg : 'xxxx',  //表示此操作的提示信息（ message ），一般只用来显示操作失败时提示信息
     data : [],  //表示此操作的返回值（ result data）
     count : x  //返回的数据条数
}
复制代码

3、版本问题

比如一个/user接口，可加上版本号例如/user/1.3，为了适配不同阶段客户端的接口。

4、接口参数校验

比如输入一个身份证号，客户端可以校验，服务器在接口侧也可以做校验。两侧建议都做校验，这样最稳妥，就怕两侧都不做校验，就扯犊子了。

5、问题接口对接

客户端定位问题，可以通过代理或浏览器扩展功能准确定位到那些细节，用事实截图及时沟通。

6、需求推诿

比如有个需求，客户端可以实现，后端也可以实现。这种情况建议后端来做，原因是后端可以统一来做，逻辑一致，降低风险，节省人力成本。如果变动变更的风险，客户端尤其是iOS客户端发版审核比较麻烦，后端的话直接一改发版后相当于热更新效果。

六、小结

总结一下，移动端本身有一套完整的知识体系，当接触到后端的体系后，才看到后端跟前端有相近的地方，也有差异的地方。每种角色都有相应的优势和劣势，以全栈的角度看技术，还是有点意思的。

当一门语言精通后，可以多种语言浅尝辄止。语言底层的规则是类似的，毕竟架构模式设计思想很多是类似的。

学而时习之，不亦说乎?