移动开发者的后端开发入门体验

大多数公司移动开发的现状

目前大多数公司移动开发过程当中都会多多少少遇到下面的这几种场景：

1. 场景A（格式）

   • 移动端：老哥，要开发了，须要把接口给我。
   • 后端：这个以前有给PC的接口，你直接调Dubbo接口吧，你用那个字段就取哪一个字段好了
   • 移动端：？？？这么多字段哪一个是我要的，为何成功的时候这个字段返回的是个json对象、失败的时候返回了个字符串。

2. 场景B （效率）

   • 移动端：各位大佬，App这边此次项目中有个功能，须要用到订单、商品和物流的信息，这个接口我应该找谁要？
   • 订单大佬：我这边只能给你订单的，其余的业务不应我去处理 商品大佬：我也是跟订单同样的。
   • 移动端：这接口没人接了。。。
   • 产品：。。。我去跟各个TL确认下，这接口归属哪边来开发

3. 场景C （在线问题解决）

   • 客满同窗：线上App报错了，弹出了个错误提示
   • 若干分钟后。。。
   • 移动端：通过排查是xxx接口返回了错误信息，因此弹出了对应提示，功能不可用，接口责任人在订单同窗那边，须要订单同窗查下。
   • 若干分钟后。。。
   • 订单同窗： 这个接口是个聚合接口，不仅有订单的信息，看了下是调用xxx接口报错了，须要sss同窗帮忙看下。
   • 若干分钟后。。。
   • sss同窗：排查完毕，是今天发布致使的，已经回滚了，目前线上问题已修复 此时已通过去了好几个若干分钟。

相信每一个移动端开发的小伙伴都或多或少的遇到过以上几种场景。

为何移动端要对后端开发有所了解

1. 做为移动端开发的小伙伴们平时要对接的开发侧的小伙伴，大多数时间段内都是后端开发的同窗，了解后端开发的相关知识，能够有利于双方之间的沟通，大大减小双方沟经过程中“大眼瞪小眼”的尴尬场景，这也就是上面所说的场景A
2. 虽然如今Android官方推荐使用Kotlin语言做为Android的开发语言，可是绝大多数Android的开发者都是使用java开发Android入的坑，学习后端开发的时候开发语言上不须要从新学习一遍
3. App端做为直接面向用户的端，接口里的内容每每不是仅仅由一个提供方提供的，例如订单列表的借口中既会有订单相关的信息，也会有购买方的用户信息，还会有所购买的商品的信息，而在实际场景中，用户、订单、商品每每是由不一样的部门负责的，这样的话给app端提供的接口的维护归属就有了分歧，任何一个改动都须要通知各方协调（场景B），当有线上问题出现时查询问题缘由也须要你们共同去查，会浪费不少人力（场景C），若是各方只提供本身相关的数据，由app端本身去组合数据提供给app端，那么责任划分和查询问题就会轻松得多。
4. 移动端开发也会须要本身的一些基础设施，如自动化构建的维护、跨平台内容的下发、热修复的管理这些都须要有本身的平台去完成，而开发这些平台最适合的莫过于咱们这些移动开发人员，由于咱们是使用方，更了解这些平台须要替咱们完成什么样的功能

如何入门

首先是选择学习的方向,选择一个合适的框架

    对于java后端的开发而言，不管是各类书籍仍是网上的博客，基本都是在SSH和SSM两种组合开发框架中作选择。

• SSH：Struts2 作控制器(controller) + Spring 管理组件 + Hibernate 负责数据库。
• SSM: SpringMVC 作控制器(controller) + Spring 管理组件 + MyBatis 负责数据库。

    SSH是比较早的项目使用的框架，在各种书籍里常常会见到，目前大多数公司使用的是SSM，Struts2以前屡次爆出了漏洞并且迭代速度并无SpringMVC 那么快，对于 Hibernate与Mybatis 的话各有优劣，打个比方的话， Hibernate 更像一个能够拎包入住的装修好的房子，功能完善，可是难以进行优化和扩展，MyBatis 像是毛胚房，须要开发人员本身装修(写sql和维护映射)，可是得益于此扩展和优化相对自由度较高，建议选择SSM好了，毕竟用的人多，遇到问题也容易找到解决方案。若是你对Spring繁琐的配置过程感到很头疼的话，建议使用SpringBoot来进行开发，由于它集齐了各种经常使用的开发框架，同时下降了 Spring 开发的门槛，更是简化了各类配置过程。

简单的后端开发用到了哪些知识

相信每一个最初接触后端开发的小伙伴都会跟我同样对后端复杂技术生态一脸懵逼，由于一上来就会接触到不少陌生的词汇，像Spring 的IOC和DI、负责数据库操做的Mybatis、缓存方面的Redis等，甚至连该怎么建立都不清楚。这些。。。。。都是正常的，毕竟没什么人样样精通。对于后端项目开发的学习，以我自身的经从来讲能够这样进行：

1. 首先是搭建后端项目的框架，固然每一个公司都会有本身的模板工程，部署完以后就能够跑起来，若是没有模版工程的小伙伴能够到https://start.spring.io/或者使用idea自动建立一个工程，
   start.spring.io自动生成工程只须要在这个页面上选择对应的条件就行了，以后把生成的工程导入Idea就能够开发了。
2. 工程能够跑起来以后就能够写提供给客户端的接口了，在这部分你须要学习建立Controller、Service、log日志的输出以及maven的依赖管理，学习这些看官方文档应该是最快的方案，https://docs.spring.io/spring-boot/docs/2.1.5.RELEASE/reference/htmlsingle/官方文档写的很详细，因此不必单独为spring买一本书去学习，由于书确定不如官网的文档更新的快，若是以为英文不太方便的话，国内也是有中文翻译的文档版本的，能够参照https://love2.io/@funkkiid/doc/Spring-Boot-Reference-Guide/README.md来学习。
3. 相信通过上面的两部份你已经知道如何给客户端提供接口了，可是光是这些是不够的，由于给客户端须要的数据每每来自各个服务提供方，例如上面举的订单的例子。这里就须要咱们从其余后端应用的服务获取数据，目前国内大多数公司使用阿里开源的Dubbo框架来对外提供服务，因此在这里咱们还须要学习Dubbo的使用，因为Dubbo框架是中国公司开源的，因此[文档]https://dubbo.apache.org/zh-cn/有中文版，学习起来会比较方便
4. 若是单纯是调用别人的服务来整合数据的话，上面三部分学习知识已经能够知足你的要求了。若是有涉及到App独立的数据须要持久化存储的话，还须要学习Mysql相关的知识以及Mybatis的使用。
5. 随着后端工程业务逐渐复杂，你可能还须要学习更多的内容来完成本身的需求：
6. 缓存方面：redis
7. 权限方面：shiro、spring security
8. 代理服务：Nginx
9. 消息：ActiveMQ
10. 数据库链接池：druid
11. 定时任务：Quartz
12. 爬虫：WebMagic

其实这些都是可选的，用到的时候再去学习就ok了

有赞移动后端基础设施所作的工做

对于有赞移动端的基础设施的工做咱们主要作了如下的内容：

1. App网关，虽然项目名称是网关，可是跟后端一般所指的网关不相同，这是一个专门给App这边提供接口的应用，开始所说的三种场景的问题，这里都可以很好的解决，由于后端同窗大多说是不了解app开发的，更多的小伙伴给App提供接口的时候会按照给前端网页提供接口的方法给接口，这种场景下App这边调用起来就会比较麻烦，在App网关中App端的小伙伴本身给app端提供接口，由App端自行维护这个应用，这样的话中台的小伙伴只须要提供本身那部分基础服务就行了，彻底不须要考虑提供出去接口的格式和接口归属的划分，同时出现线上问题App端的小伙伴也能够直接定位到是哪一个服务出现了问题，能够减小线上故障的时间。App网关结构以下图所示：。在服务化的过程当中前段同窗也使用node作过相似的处理，感兴趣的同窗能够移步Node 在有赞的实践，只不过不一样点在于：App网关里有一部分app端自有的业务逻，没有页面渲染的功能。
2. MBD，因为业务线比较多，你们都在本身机器上打包的话比较耗时间，也没办法对安装包的构建过程作统一的管理，因此开发了MBD来进行正式包、测试包和热修复以及二方库构建的管理。
   Apub，用于app应用新版本和热修复的下发和灰度，同时与MBD打通，能够实现从构建到发布、热修复、交付一系列流程的打通。
3. Weex构建平台 ，相似于MBD的功能，对应的场景非原生发版，而是weex发版，使得开发人员能够更关注于业务自己，便捷的在不一样环境全量、灰度发布weex页面。
4. 配置中心，随着App功能的迭代，App端的配置日益增多：各类功能的开关、参数的配置、网页url的地址……
   对配置动态化的指望值也愈来愈高：配置修改后实时生效，灰度发布，分环境，同时对于运营人员而言，也不但愿每次修改信息都由开发人员帮忙修改代码发布。
   在这样的场景，传统的经过移动端或者后端代码中hardcode发版、修改数据库等方式已经愈来愈没法知足开发人员和运营人员对配置管理的需求。因而咱们开发了移动配置中心来知足这些需求。
   配置中心中能够对不一样的功能划分不一样的组件，给运营人员和开发人员发布新配置的功能，新的配置能够经过有赞IM的长链接和App先后台切换去主动拉取配置，达到实时生效,通过数个版本的迭代，还接入了移动基础保障发布权限的审批、Apub的灰度发布功能。
5. 移动基础保障平台，用于移动端管理平台上的权限管理和审批、app端应用日志的捞取和用户设备信息的查询、以及app内应用反馈的处理，配置中心基础功能见下图：

感觉&收获

1. 客户端的开发更加注重的是用户的体验，是用户操做时的具体感觉，面向的是单个用户，而服务端开发更注重的是功能和数据，是线上功能的可用性及数据的准确性。
2. 虽然客户端和后端都会考虑应用的性能，可是二者侧重点不一样，客户端更看重用户使用的感知，如动画效果及滑动流畅性，然后端更看重的是运行效率和并发能力。
3. 客户端在开发的过程当中并发的场景比较少，切换线程一类的操做比较多，而服务端恰好相反，服务端场景下用户并发的场景会不少，线程切换类的操做却是不如客户端那么频繁了，这与系统的限制及面对的场景相关，客户端只面对一个用户和服务端，而服务端须要面对多个用户。

讲座【特别推荐】

Spring Boot 系列文章如若不解，能够经过讲座进行进一步学习。

手把手的跟大家一块儿Coding，你快来。

1. Spring Boot 1.5 快速入门教程
2. Spring Boot 1.5 进阶
3. Spring Boot 系列教程（入门+进阶） 【SF编辑推荐】