大多数公司移动开发的现状
目前大多数公司移动开发过程中都会多多少少遇到下面的这几种场景：
- 移动端：老哥，要开发了，需要把接口给我。
- 后端：这个之前有给PC的接口，你直接调Dubbo接口吧，你用那个字段就取哪个字段好了
- 移动端：？？？这么多字段哪个是我要的，为什么成功的时候这个字段返回的是个json对象、失败的时候返回了个字符串。
- 移动端：各位大佬，App这边这次项目中有个功能，需要用到订单、商品和物流的信息，这个接口我应该找谁要？
- 订单大佬：我这边只能给你订单的，其他的业务不该我去处理 商品大佬：我也是跟订单一样的。
移动端：这接口没人接了。。。
- 产品：。。。我去跟各个TL确认下，这接口归属哪边来开发。
- 客满同学：线上App报错了，弹出了个错误提示
若干分钟后。。。
- 移动端：经过排查是xxx接口返回了错误信息，所以弹出了对应提示，功能不可用，接口责任人在订单同学那边，需要订单同学查下。
若干分钟后。。。
- 订单同学：这个接口是个聚合接口，不只有订单的信息，看了下是调用xxx接口报错了，需要sss同学帮忙看下。
若干分钟后。。。
- sss同学：排查完毕，是今天发布导致的，已经回滚了，目前线上问题已修复此时已经过去了好几个若干分钟。
相信每个移动端开发的小伙伴都或多或少的遇到过以上几种场景。
-
作为移动端开发的小伙伴们平时要对接的开发侧的小伙伴，大多数时间段内都是后端开发的同学，了解后端开发的相关知识，可以有利于双方之间的沟通，大大减少双方沟通过程中“大眼瞪小眼”的尴尬场景，这也就是上面所说的场景A。
-
虽然现在Android官方推荐使用Kotlin语言作为Android的开发语言，但是绝大多数Android的开发者都是使用java开发Android入的坑，学习后端开发的时候开发语言上不需要重新学习一遍。
-
App端作为直接面向用户的端，接口里的内容往往不是仅仅由一个提供方提供的，例如订单列表的接口中既会有订单相关的信息，也会有购买方的用户信息，还会有所购买的商品的信息，而在实际场景中，用户、订单、商品往往是由不同的部门负责的，这样的话给app端提供的接口的维护归属就有了分歧，任何一个改动都需要通知各方协调（场景B），当有线上问题出现时查询问题原因也需要大家共同去查，会浪费很多人力（场景C），如果各方只提供自己相关的数据，由app端自己去组合数据提供给app端，那么责任划分和查询问题就会轻松得多。
-
移动端开发也会需要自己的一些基础设施，如自动化构建的维护、跨平台内容的下发、热修复的管理这些都需要有自己的平台去完成，而开发这些平台最适合的莫过于我们这些移动开发人员，因为我们是使用方，更了解这些平台需要替我们完成什么样的功能。
如何入门
对于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等，甚至连该怎么创建都不清楚。这些。。。。。都是正常的，毕竟没什么人样样精通。对于后端项目开发的学习，以我自身的经历来讲可以这样进行：
-
首先是搭建后端项目的框架，当然每个公司都会有自己的模板工程，部署完之后就可以跑起来，如果没有模版工程的小伙伴可以到https://start.spring.io/ 或者使用idea自动创建一个工程
start.spring.io自动生成工程只需要在这个页面上选择对应的条件就好了，之后把生成的工程导入Idea就可以开发了。
-
工程可以跑起来之后就可以写提供给客户端的接口了，在这部分你需要学习创建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 来学习。
-
相信经过上面的两部分你已经知道如何给客户端提供接口了，但是光是这些是不够的，因为给客户端需要的数据往往来自各个服务提供方，例如上面举的订单的例子。这里就需要我们从其他后端应用的服务获取数据，目前国内大多数公司使用阿里开源的Dubbo框架来对外提供服务，所以在这里我们还需要学习Dubbo的使用，由于Dubbo框架是中国公司开源的，所以[文档] https://dubbo.apache.org/zh-cn/ 有中文版，学习起来会比较方便。
-
如果单纯是调用别人的服务来整合数据的话，上面三部分学习知识已经可以满足你的要求了。如果有涉及到App独立的数据需要持久化存储的话，还需要学习Mysql相关的知识以及Mybatis的使用。
-
随着后端工程业务逐渐复杂，你可能还需要学习更多的内容来完成自己的需求：
-
-
-
-
-
-
-
其实这些都是可选的，用到的时候再去学习就ok了。
有赞移动后端基础设施所做的工作
对于有赞移动端的基础设施的工作我们主要做了以下的内容：
-
App网关，虽然项目名称是网关，但是跟后端通常所指的网关不相同，这是一个专门给App这边提供接口的应用，开始所说的三种场景的问题，这里都能够很好的解决，因为后端同学大多说是不了解app开发的，更多的小伙伴给App提供接口的时候会按照给前端网页提供接口的方法给接口，这种场景下App这边调用起来就会比较麻烦，在App网关中App端的小伙伴自己给app端提供接口，由App端自行维护这个应用，这样的话中台的小伙伴只需要提供自己那部分基础服务就好了，完全不需要考虑提供出去接口的格式和接口归属的划分，同时出现线上问题App端的小伙伴也可以直接定位到是哪个服务出现了问题，可以减少线上故障的时间。App网关结构如下图所示：
在服务化的过程中前段同学也使用node做过类似的处理，感兴趣的同学可以移步 Node 在有赞的实践，只不过不同点在于：App网关里有一部分app端自有的业务逻，没有页面渲染的功能。
-
==MBD==，由于业务线比较多，大家都在自己机器上打包的话比较耗时间，也没办法对安装包的构建过程做统一的管理，所以开发了MBD来进行正式包、测试包和热修复以及二方库构建的管理。==Apub==，用于app应用新版本和热修复的下发和灰度，同时与MBD打通，可以实现从构建到发布、热修复、交付一系列流程的打通。
-
Weex构建平台 ，类似于MBD的功能，对应的场景非原生发版，而是weex发版，使得开发人员可以更关注于业务本身，便捷的在不同环境全量、灰度发布weex页面。
-
配置中心，随着App功能的迭代，App端的配置日益增多：各种功能的开关、参数的配置、网页url的地址……
对配置动态化的期望值也越来越高：配置修改后实时生效，灰度发布，分环境，同时对于运营人员而言，也不希望每次修改信息都由开发人员帮忙修改代码发布。
在这样的场景，传统的通过移动端或者后端代码中hardcode发版、修改数据库等方式已经越来越无法满足开发人员和运营人员对配置管理的需求。于是我们开发了移动配置中心来满足这些需求。
配置中心中可以对不同的功能划分不同的组件，给运营人员和开发人员发布新配置的功能，新的配置可以通过有赞IM的长连接和App前后台切换去主动拉取配置，达到实时生效,经过数个版本的迭代，还接入了移动基础保障发布权限的审批、Apub的灰度发布功能。
-
移动基础保障平台，用于移动端管理平台上的权限管理和审批、app端应用日志的捞取和用户设备信息的查询、以及app内应用反馈的处理，配置中心基础功能见下图：
感受&收获
-
客户端的开发更加注重的是用户的体验，是用户操作时的具体感受，面向的是单个用户，而服务端开发更注重的是功能和数据，是线上功能的可用性及数据的准确性。
-
虽然客户端和后端都会考虑应用的性能，但是两者侧重点不同，客户端更看重用户使用的感知，如动画效果及滑动流畅性，而后端更看重的是运行效率和并发能力。
-
客户端在开发的过程中并发的场景比较少，切换线程一类的操作比较多，而服务端刚好相反，服务端场景下用户并发的场景会很多，线程切换类的操作倒是不如客户端那么频繁了，这与系统的限制及面对的场景相关，客户端只面对一个用户和服务端，而服务端需要面对多个用户。