废旧手机回收会是手机厂商未来的一个大生意?
　　根据中国信息通信研究院的数据显示，2016年国内市场出货量为5.6亿部，未来几年每年更新量可能达到4亿至5亿部，而此前已经沉积了约10亿部手机。
　　根据工信部最新的统计数字，截至2016年11月，中国手机用户已达13.2亿。智能手机每年的淘汰量也达到3-4亿，但率不足2%。随着手机厂商年年发新机，那么意味着旧手机会越来越多，电子废弃品对于当前的生态环境来说，是一大隐患。另有数据显示，中国每年电子垃圾年产量有230多万吨，成为世界第二大电子垃圾生产国。
　　随着人们环保意识的不断提升，过去不太受到重视的废弃电子垃圾回收行业开始引起人们的关注。比如说早前国际环保组织呼吁三星公开召回Note7的处理计划。而2014年版《废弃电器电子产品处理目录》也已将手机列入其中。如何解决这个问题已经成为政府、许多厂商的重大课题。
　　在目前，正是每年有3亿-4亿部旧机被淘汰，催生了2000亿元左右的手机回收市场。许多交易市场中以旧换新的电子产品市场，旧手机成为重要的交易单品。当前回收旧手机的品台有以爱回收网、回收宝、友通商城等电子回收平台，以及以闲鱼、转转、百姓网为代表的综合二手平台。
　　二手交易市场虽然可以将旧手机二次利用价值释放出来，但在二手交易市场，买卖双方也大都为个人行为，这时候，问题接连产生，比如手机定价难以规范、问题描述的沟通成本太高、平台对于交易双方的诚信规范尚不成熟、放鸽子或者交易欺诈现象时有发生，成交效率太低。
　　说到底，这类二手交易市场让从发布信息，到买家找到卖家、或者买家找到卖家、讨价还价、交易完成或者被放鸽子、退货，整个交易过程的时间成本太长太繁琐，这些交易过程中的诸多痛点导致用户也不愿在二手交易市场交易。所以我们看到国内早前相关数据显示，七成旧手机被闲置在家。许多消费者心中的&二手交易市场&是&低价甩卖&的平台，认为旧手机在这些平台上出售，是很难博得一个好价钱，索性就将其闲置处理。
　　因此，手机厂商事实上是站在旧手机回收链条上最有利的位置，它相对二手交易平台来说，手机厂商回收旧手机，即便定价不合理或者偏低的问题，用户是可以接受的，因为它无需消耗用户讨价还价的时间成本以及交易过程中的沟通成本，以及避免了交易过程中的欺诈现象，关键是渠道正规、用户对其信任度高。
　　正是由于二手回收市场存在着诸多不规范现象以及局限性太大、交易过程有太多痛点没有解决，所以，手机厂商们建立旧手机回收机制往往可以收到更好的效果。况且手机厂商需要拉动新机的销售，还面临着手机零部件成本上涨的问题，在手机中，各种零部件、有色金属、黑色金属、塑料、玻璃、面板等材料依然具有很大的价值。既避免了对生态环境的污染，也能产生新的经济效益。
　　在国内，华为、魅族、oppo等厂商过去也有在做以旧换新服务，以一定的估价回收，让消费者加价购买指定型号的新品，并且有效拉动了门店的销售业绩，但国产厂商更多是小规模试水以旧换新服务而不是大规模推广并且提到重要的营销战略规划上来。
　　在当前来看，随着手机用户旧手机存量越来越多，闲置手机太多已经成为阻碍用户购买新机的一个重要考虑因素，以旧换新提高用户换机的积极性，把非换机用户转变为目标客户群，也可能成为影响手机厂商利润增长的重要一环。电子垃圾甚至已经影响到环保，如何变废为宝也是考量着厂商们的智慧。
　　对厂商们来说，回收后的手机可以竞价卖给下游回收厂商，或者拆解元器二次利用应对今年手机元器件价格大涨的局面，或者可以从中提炼贵重金属。比如说由取得专业认证的回收合作商从中提取黄金与黄铜这样的金属材料。至于其余的部分，可以利用做铝合金窗架、家具以及玻璃瓷砖。
　　厂商们也可以学习纬创，纬创最近几年开始做售后服务与回收业务，纬创的做法是，把维修中报废的电子产品回收再加值，在附加价值更高的电子废金属部分，纬创则以两千万美元，入股全球顶尖的高科技金属回收公司佳龙科技，双方共同研发出最新的化学处理工艺，高效能提炼金、银、铂、硅、铜等贵重金属二次利用。
　　某手机回收平台创始人介绍说，每吨废旧手机中能提取出150克左右黄金，而每吨金矿石则只能提取到5克，相差近30倍。
　　苹果就是一个变废为宝的典型。苹果的策略是把翻新出售，或者提炼重要贵金属。有外媒给出的数据是，苹果公布的环境报告显示，通过回收和智能手机，他们获得了超过6100万磅钢、铝、玻璃和其它材料，而且还获得了2204磅(约合999.7千克)黄金。苹果公司早前也表示在2014 年中他们从废旧设备中回收了超过 4 万吨电子垃圾，这其中回收的钢铁已经足够建设一条长达 100 英里(约为 161 公里)的铁路。苹果通过回收旧电脑和智能手机获得了价值近4000万美元的黄金，折合人民币2.6亿元左右。对于苹果来说，以旧换新是它推动消费者换机，驱动产品迭代升级的重要策略。况且通过提炼贵金属苹果也收益颇丰。
　　在国内市场，这种以旧换新也应该成为手机行业一种有效的营销方式，对于当下的手机用户来说，如何处理掉抽屉里的旧手机已经非常头疼，也存在着巨大的需求。在当前的做法来看，苹果值得其他厂商借鉴。今年3月，在推出iPhone 7半年后，苹果再一次上线以旧换新服务，这一次苹果甚至将旧手机的类别扩展到了Android手机。
　　这对于手机厂商来说，通过贴补购买新手机费用的消费者，同时又建立了一种回收二次销售或者重要元器件提炼机制，对于行业来说，有效的回收利用也一种良性循环的机制，因此，总的来说，拉动用户对废旧手机的处理，以销量带动其上行势头，是手机厂商未来拉动销量甚至新的增长点的重要竞争力环节。
　　在这方面，手机厂商可以设计一套完整的价值估计体系，让用户可以在网站或者APP里拿二手机换取不同的商品，也可以二手机+现金换取手机等商品。其次建立一套分级的流程处理机制，针对较新、损坏程度较小的手机经过分类处理、翻新后放到;损坏程度较深的手机，可以将可用零部件拆解再利用。另外，还可以提供专业化的鉴定保障、合理估价以及清洁翻新等增值服务。
　　况且当下手机厂商都在走线下渠道，而推广线下渠道则需要吸纳人气，以旧换新政策与线下渠道模式有着很好的契合点，拉动新机销量也有很好的效果。如前所述，当前难点在于，如何建立一整套回收再利用的技术与渠道销售流程，真正让回收到的旧手机转手赚到钱。
　　笔者认为，未来几年，二手机回收市场可能是手机厂商的一大争夺的增长点。
您看到此篇文章的感 受是....
图 说 家 电
本 周 热 门 作 者
国美、苏宁，从同一个商业模式发展到今天，已经逐渐分道扬镳。
未来3到5年，在完全开放的道路上能够替代司机的无人驾驶汽车将会出现。
乱象背后，则是十余家网络平台的推波助澜。【系统设计】我们是如何一个半月从无到有打造一个互联网回收平台的 - 简书
【系统设计】我们是如何一个半月从无到有打造一个互联网回收平台的
我们接到一个需求，开发一个互联网废旧垃圾回收平台。需求方只是一个想法，技术团队如何落地，不仅仅涉及到系统设计，更重要的是先梳理清业务链路。
废旧品处理厂期望直面普通用户进行废物回收，这是一个串行的长链路业务，所以我们以业务参与人员的角度切入分析：
用户Customer
用户可以通过微信公众号，手机App，官网进行回收呼叫，另外考虑到部分老年用户不太会用手机，需要同时支持400热线电话
客服CustomerSupportor
客服人员一方面对于用户发起的呼叫进行审查，因为回收业务是强依赖地址的，需要确保相应订单尽可能准确，否则直接派送回收人员会造成一些问题。
另外一方面，对于直接通过热线电话发起的回收呼叫，我们需要客服人员进行会员注册，订单创建等操作。
此外，对于用户投诉，车辆故障等突发问题，需要客服协调解决。
调度员Dispatcher
对于回收订单分配，考虑到项目上线时间和初期规模，不会有特别智能的订单分配策略方案（路线规划，订单分派，车辆负载检查等），所以通过调度人员进行订单分派补偿，才能保证业务平稳运行。
另外考虑回收后，需要给用户付钱，回收人员需要统一携带现金，并每日进行核对，也需要调度员这样一个和回收员紧密联系的角色进行资金汇总分发等操作。
调度管理员GeneralDispatcher
主要是能看到基于地图的全局数据大盘和综合业务数据汇总（例如总车辆，总回收单数，总服务用户等）。
回收员Recycler
支持接单，接收审核后调度分派的订单，然后找到用户，审核废旧品，并贴上全局唯一的条码，实现全链路追溯，录入系统相应订单和回收物品，完成2C的付款。
支持现场帮用户下单，考虑有些用户看到工作人员后可能会现场回收。
支持对订单做一些操作，例如拒绝接收改单，完成该订单，停止接单，汇报车辆负载等。
仓储：需求是打通上下游，那么废旧品集中回收后，需要运送到专门的仓库进行分拣归类，然后统一配送给末端处理企业，这就要求有相应仓储工作人员接入。
仓储_原料入库下货员
回收车辆进入仓库后，由下货员进行废旧品卸货，扫描回收品上的全局唯一条码，核对物品类型是否与回收员现场录入的物品类型一致，核对整车物品数目是否和系统一致。之后将物品放入循环传送带上，交由下一个环节处理。
仓储_原料分拣员
分拣员按照废旧品类型分组，例如电视机线，冰箱线，电脑线，手机线，纺织品线等。具体操作可以从主传送带上拿取自己负责的物品类型，进行扫码装框（每个框子是国家标准制作的大铁笼），这样我们就知道一个在客户A回收的类型为电视机20寸的物品1001，最终被分拣线工人识别为类型电视机20寸，并装入了31框。当然回收员因为自己的专业知识可能会对物品规格识别错误，这里有可能出现仓库分拣的物品类型与回收员录入的物品类型不一致的情况，我们需要识别分析进行报告。
分拣完成后，当一个框子满框，分拣员触发入库操作，会自动打印入库单，并通知叉车员将整框同类型物品送往称重台称重，称重之后放置于指定存储区域，叉车员通过入库单进行搬送业务，并不直接在系统中参与到业务链路中，可以通过人工喊话进行沟通。
仓储_成品入库称重员
通过电子秤，直接获取框以及满框物品的总重量，减去框标准重量，就得到了物品总重，称重员扫描框码，确认重量，打印标准入库单，表明框号，批次号，类型，数量，重量并录入系统中，之后由叉车员放入成品存放区。
仓储_成品出库员
当运营人员发现某类型废旧品分拣成品达到一定数量，联系相应终端处理企业出库，此时会有一辆大货车，在出库员处录入企业信息，车辆信息，司机信息，生成预出库单，凭借预出库单，前往大电子秤处称空车重量，然后返回仓库出库口，进行出库品装载，每个框出库时进行扫码，这样系统就知道哪些物品，多重的物品，被哪个企业接收走了。
仓储_成品出库称重员
对出库车辆进行空载称重
对出库车辆进行满载称重
仓储_管理员
看到所有物品的仓储情况
看到所有仓储人员的处理数据
特殊权限针对物品做强制出入库，报废，订正等操作
全量订单数据
全量支付数据
全量仓储数据，包括库存，入库，出库，各种进销存
定制化报税单
全量人员数据
至此整个业务链路基本处理完毕，对于终端处理企业，由于数目众多类型众多，我们无法再进行更深一步的打通。
核心业务模型抽取
账户Account
用户，客服，调度，仓储人员需要统一的核身逻辑，所以我们要打造规范的账户体系。账户的核心抽象实际上就是登陆凭证，我们通过Account模型，内含登录名，登录密码，账户类型等关键字段，就可以完成统一核身和权限管控。另外对于不同的业务参与者Customer，CustomerSupportor等，其描述字段很不相同，例如用户有用户昵称，但是对于Supportor没有，但是Supportor却有坐席编号（方便呼叫系统进行热线转接），所以参与者具体模型Customer等与Account以一一对应的关系设立。这样微信公众号中的OAuth验证，我们就会创建WechatUser模型，将其与Customer进行一一关联绑定。这样实现了全站统一的账户体系，Account成为核身领域模型。
回收单RecycleOrder
对于用户来说会进行呼叫回收操作，其包含呼叫人，呼叫时间，回收内容等相关成员。
客服工单SupportorWorkOrder
为了对客服工作进行审计，以及客服通话记录的管理，我们需要客服工单模型，为什么这部分没有并入订单原因也很简单，一个订单可能有多次咨询，会产生多个客服工单；另外一些咨询投诉，可能并不强关联任何一笔回收单，所以客服工单从产生角度，关联关系，成员数据来看，都应该是独立模型。
回收工单RecyclerWorkOrder
用户产生回收单后，实际是需要回收人员上门处理的，订单分配由调度员产生，所以在回收单基础上我们设立了回收工单，其主要属性包括：回收单承担人，回收单创建时间，派送时间，考虑到以后可能会赋予回收员更多的业务处理能力，例如搬家，商品配送，我们希望工单模型相对独立，是对回收单，以后可能产生的搬家服务单，商品配送单的接口模型。
业务端回收物品Item
全局唯一可追溯的回收物品模型，包含物品类型，规格，关联订单，处理人等信息
仓储段回收物品Item
考虑到面向用户的物品分类和面向仓储末端处理企业的物品分类不尽相同，我们在仓储端需要另一种回收物品模型。
仓储入库单WarehouseInOrder
仓储出库单WarehouseOutOrder
除了上述核心模型外，其它模型例如用户地址Address，车辆Car，车辆位置CarLocation，回收品类Category，SubCategory，规格Spec，城市City，全局唯一框Backet，分拣员等模型其实本质都是对于上述核心模型的描述和补充。
我们在进行系统划分时遵循的几个基本原则：
方便高效开发。最少的代码，最少的重复工作，最快的产生结果。
功能职责单一，高扩展，避免耦合。
系统单元与业务单元尽可能保持一致。
由复杂到简单，由深到浅。不能只按最简单的来，最简单就是一个web应用 + 一个mysql全部搞定，我们应该按照能想到的最细粒度的方式入手，然后根据实际情况和需求往上层走。
梳理整个系统功能边界，哪些功能要自己实现，哪些功能是要调用第三方，这些服务是面向局部的还是面向全局的。
迭代。花必要的时间进行多种方案的头脑风暴和不断推演。
梳理技术难点。难点有两个角度，一是公认的技术难点，例如分布式环境中保证强一致性；一是团队不熟悉的技术，例如java开发团队面临前端开发任务或者去开发一个windows桌面应用。
时刻牢记项目投资规模，初期性能要求以及上线时间，避免过度设计和开发。
保持强的领域意识。就是说当我们划分出一个系统后，我们要站在这个系统的内部，作为系统owner思考该系统的边界，那些事情作为系统owner愿意做，哪些事情作为系统owner不愿意做。
主导者应预先思考一个设计方案，否则在团队头脑风暴时会容易发生讨论发散，主线不清，结果不明。
提取领域模型。通过参与人角度非常有利于分析业务链路和梳理前端入口，但是对于后端系统划分不够深入，所以需要提取领域模型，基于领域模型做后端系统划分更加合适
我们的划分过程经历多轮头脑风暴和迭代，具体过程就不详细展开了，直接看看最终的方案
互联网回收系统
呼叫回收模块
前端：客户app
前端：客户微信公众号
前端：客户官网
前端：回收员app
前端：客服Web页
前端：调度Web页
基于用户Customer，客服CustomerSupptor，调度人员Dispatcher的行为进行领域模型抽象，回收单RecycleOrder，客服工单CustomerSupportorOrder，回收工单RecycleWorkOrder相互持有，且有很多共同属性例如都是基于Account模型。所以将这三个模块并入一个系统开发，有利于实现代码复用，减少工作量。
如果将三者划分成三个独立系统，代价是必须要实现单点登录，即增加一个独立的核身系统AccountSystem，另外三个模块紧密耦合，划分会带来大量的跨系统调用，进而需要引入分布式框架保证一致性和代码解耦，结合项目上线时间，投资规模，和实际使用量来看，不适合划分过细。
因为没有足够的技术资源和专业的运维人员，选择Spring Boot这种轻量级的开发部署框架
选择Spring MVC，一方面是有相关开发经验，另一方面阿里系基于Spring框架做到这样一个体量，相关文档和解决方案很多，系统扩展潜力会比较大。
此外使用了Spring Security做安全架构LogBack做日志框架，Spring Test做接口测试。
因为业务模型梳理较为细致，且考虑了扩展性，例如客服工单独立，回收员工单模型独立，足以支持以后上线的搬家服务，商城服务。我们有足够的信心不会大范围发生领域模型变化，所以采用Hibernate以及Spring JPA来实现持久化层的代码。
考虑一期的预期调用量，MySQL足以应对，底层数据存储使用阿里云MySQL双机版。
考虑静态资源访问可能消耗珍贵接口带宽，静态资源统一采用CDN存储
考虑业务稳定性，灾备，以及线上无感知发布更新，系统采取3机部署，通过前挂LBS实现负载均衡，LBS可以采取nginx或者阿里云现成服务。
多模块耦合导致系统代码复杂，影响水平扩展，长久来看还是要做更细一步的拆分的
对外调用支付宝接口，微信支付接口进行企业=》用户的付款，付款查询等操作
对回收系统提供调用接口，回收系统不需要识别支付细节，只需要告知支付系统支付对象，支付金额，支付原因，支付渠道即可
支付系统不同于常见的电商支付系统是用户向企业付款，有问题可以走退款链路。而是由企业账户打款到用户账户，因为回收业务是要给用户付钱。基本所有支付机构都是不可逆操作。而且该接口都是直连企业第三方支付的企业账号，对账号内资金具有全部操作权限，所以该系统的安全要求和门面系统不可同日而语。单独划分系统后，可以通过防火墙，ip白名单等等策略，限制入口调用和出口调用，关闭无关端口，走单独的运维策略，在初期项目技术资源有限的条件下，保证其安全性。
回收系统不应当耦合不同支付渠道的实现细节，不应当识别不同支付机构的接口代码，因为其本身承担了三个模块的代码，再耦合支付系统复杂性和维护性就不在一个可以接受的水平上了。
Apache Tomcat
Spring MVC（对业务系统提供基于Http的REST调用接口，并有相应的回调逻辑）
MyBatis（主要了是为了扩宽技术栈，所以没有用Hibernate）
基于传统的同步调用异步回调实现，代码不够简洁，还耦合回收系统业务代码（订单查询保证幂等），应该采用消息机制实现更合理的系统调用。
数据库独立，在后期数据汇总时，例如一个数据报表需要从回收系统数据库和支付系统数据库同时出，带来了一些复杂性。
仓储操作端：用C#写的运行在windows上的GUI应用，通过DLL对接打印机，通过串口对接电子秤，通过USB对接扫码枪
仓储服务端：提供基于Http RESTFul的接口，提供物品入库，分拣，称重，出库等等请求。
从业务逻辑上和领域模型上看，仓储系统相对很独立，唯一与主系统耦合的点在，物品入库时请求主系统获取该物品类型规格回收人员等。
该系统涉及到对接其它设备较多，这些技术点与回收系统，支付系统，不相关。
仓储系统有特殊的稳定性和私有化部署要求，即使回收系统故障，也不应该影响仓储系统运作，例如回收系统故障，但是仓储系统应该能够正常出入库。
Apache Tomcat
Spring MVC，Shiro，Log4j
客户端采用C#导致扩展升级不变，仓库里投放了多台壁挂式一体机，成本较大，如果采用手机App作为操作员端，会更加合理（类比快递员的手持设备）。我们之所以采用C#一方面是考虑开发成本，C#有拖拽式界面IDE，另外传统的磅秤，打印机对windows有良好的调用支持，如果采用App的话，需要自研中间服务，实现操作端对打印机，电子秤的交互，考虑我们时间资源有限，没有采用，准备在第二个分拣仓库建设时进行重构。
因为回收系统Account没有开放出来，导致仓储系统无法实现单点登录，只能自己也存储了仓储人员信息，也重复了一些身份验证代码，但是后期实践时发现仓储的身份核验和回收系统不太一样，管理要求也不一致，所以整体来看，不是特别大的问题。
数据库独立，在后期数据汇总时，例如一个数据报表需要从回收系统数据库和仓储系统数据库同时出，带来了一些复杂性。
仓储系统业务模型相对稳定，并发要求不高，应该采用Hibernate进行持久层而不应该采用MyBatis
400呼叫系统
400呼叫系统主要职责是将用户打进的电话分配到7个坐席人员的电脑上，坐席人员通过耳麦和网络与用户沟通完成服务。职责功能非常单一，就是实现电话呼入功能。
目前的坐席呼叫系统本质都是把用户通过手机也好，固话也好，电信会将用户呼入通过专线投递给呼叫设备，呼叫设备下挂语音IP卡，将语音数据转化为可以基于网络传输的数字语音数据，然后定向发给与呼叫设备相连的电脑端，这样达成坐席通过电脑耳麦和网络与用户进行对话。
另外一种方案是云坐席方案，顾客本地不需要购买呼叫设备，所有客服人员打开网页，通过flash建立和云中心的链接，云中心部署了呼叫设备完成与电信的信号对接。但是这种云坐席要价比较高，另外稳定性难以保证，与自有系统不好对接，所以我们采用了第一种。
呼叫系统接收一个来电，分配好坐席后，我们需要相应的坐席人员能够根据来电号码查找是否注册用户，查找其关联订单，关联客服工单等信息。最终解决方案是，呼叫系统定制化开发，坐席接通后post相关来电信息（来电号码，坐席编号）到回收系统客服模块，回收系统后端与客服前端通过WebSocket保持链接，一单后端接收到来电就发送信息给前端页面，前端页面通过js进行用户信息查询，订单查询等操作并刷新页面。
呼叫系统初期只是通过简单的路由设备和坐席人员联通，稳定性很差，因为局域网不同部门公用，经常波动。后来接入另一个地点的外包客服，根本不在内网，带来了更大挑战。这之中，学习了组网知识，购买了企业级路由器，建立了呼叫设备与本地坐席和远程坐席的VPN链路，稳定性安全性得以保证。这中间经历了不知道多少坑，和华为技术支持，电信技术支持，外包坐席网络工程师接连对接了N次，付出很多也学到很多。
呼叫系统是一个.NetFramework + SQL Server的本地服务器模式，定制化开发比较难，和业务系统对接不容易，例如我们想实时获取一段通话录音，很难从SQL Server的库里导出，制作音频文件，这一步目前往往都是人工实现。另外呼叫系统自带评分机制，这个数据也是需要人工同步。
数据报表系统
我们在分析财务人员和仓储管理员需求时发现，他们的核心诉求是各种维度，各种组合的数据汇总，这些数据汇总没有固定的业务模型对应，另外他们的诉求往往需要我们进行跨数据库的查询，而跨库数据交换在前面几个业务系统中往往通过接口调用实现。
基于实际的需求，数据报表在代码逻辑上非常薄，数据层实现多数据源抓取，上面封装一些数据整合，缓存，分页等功能，以标准的json或者map设置就可以直接返回给前端了，前端基于ECharts或者D3或者JQWidget就可以做渲染了，这和其它系统处理链路是很不相同的。
另外还有一个原因，我们团队有位同学是前支付宝平台数据部的数仓工程师，SQL能力很强，所以大部分的数据报表，我们能够很快得写出高效的查询语句。
Apache Tomcat
Spring MVC，Shiro，Log4j
多个MySQL数据库
系统涉及多数据源，涉及到跨库join，如果我们的数据库考虑其稳定性放置在不同的MySQL实例中，是无法直接通过SQL实现一些合并操作的。一期我们通过代码，讲两个库查询到的数据分别缓存起来，然后按照呈现逻辑进行整合，代价是增加了系统复杂性，消耗了报表系统的性能
二期，我们做了妥协，将多个系统的独立数据库合并到了一个MySQL实例中，大部分数据集合的操作通过SQL实现。结果是，上层业务系统独立，数据库独立，但是数据服务器不独立。从运维管控和扩展性来讲，都不是很合理。
三期，未完成，最终梳理的解决方案是，将数据报表需求分为两部分，一部分是实时数据展示，一部分是非实时数据展示。
实时数据展示涉及到跨库join的场景很少，复杂性低，可以通过接口调用缓存本地，然后用代码处理数据合并，和一期保持一致；
非实时数据，可以通过数据仓库，每天定时将分布在多个数据库的数据进行抓取清洗，然后存放起来，需要查询时可以直接访问数仓，或者由数仓回写到指定数据库，访问相应的数据库。这样的好处是，数仓借用阿里云彩云间也即ODPS，是不用耦合业务代码的，其所有操作通过类SQL操作即可实现，从而将数据join，清洗的工作与代码解耦。大家稍微看下数仓的理念或者了解下阿里采云间就会明白。
B2B电子订单系统
这是一个后期补充需求，业务模型相对独立，主要是为了方便终端处理厂可以电子化的和仓储运营人员进行货物买卖。举个例子，末终端处理厂，需要2000个触屏手机，或者1吨废旧衬衫，都可以在该系统中下采购单；同时，他也能通过该系统，获得仓储中物品规格数量的大致信息，根据现有数量和物品下采购订单。这样就将废旧品出库采销整体打通并实现电子化
前段采用基于MVVM的angularjs，是缺少专业前端人员团队进行前端开发的利器
Spring Boot
Spring MVC, Spring Security, LogBack
至此，回收平台系统已经设计完毕，技术选型也初步确定。项目成功上线，除了因为某些小bug造成的单点故障，在设计规模下，没有发生因系统设计不合理引发的问题，系统扩展性也比较强，对于新增业务基本能够很好得支持。
代码仓库：我们的全部代码初期存放于gitoschina上，后来一段时间经常服务异常，无法commit，所以转移到了aliyuncode，非常稳定，速度很快。
持续集成：我们基于jenkins做了全部系统的持续集成，支线代码提交就会部署开发环境，主干代码更新就会部署测试环境，生产环境部署也是一键达成。其中很多小点还是值得分享的，具体我会在其它博文里介绍。
代码工程：我们打造了非常规范，并经过实战优化的Spring Boot多Module工程目录，晚些也会在专题博文里分享介绍。
依赖管理：一般项目用的Maven，一般项目用的Gradle，对比来说，更喜欢Gradle，配置灵活功能强大。
埋点实现：
业务埋点通过打印日志，然后使用阿里云日志分析服务实现
访问埋点通过友盟，功能强大稳定，好像已经被阿里收购了
App埋点通过腾讯bugly，非常好用，追踪安装量，打开量，异常很方便，还有在线模拟器可以用，强烈安利！
静态资源通过阿里云CDN服务支持访问，资费很低，节约了系统服务器的宝贵带宽
车辆定位使用了G7货运人，还是比较稳定的，中间出过一次问题，及时找到对方技术接口人并解决，此外定制开发也能找到接口人，效率也挺高。
WebSocket使用了leancloud，但是稳定性有段时间不好，后来基于开源自建了一个Socket服务器。
短信服务初期使用leancloud，送达率略低，后期切入阿里大于，自费和送达率都符合业务要求。
微信开发，因为有微信公众号，所以对接了微信的各种接口，也填了微信浏览器的各种坑，具体细节会在其它文章分享
支付开发，对接微信支付，支付宝支付，相关分享会在其它专题文章里讲述。
前端框架，使用了angularjs，不得不说是后端MVC人员转型前端开发利器啊。
前端框架，报表使用了JQWidgets，非常好用
MVC异常处理，我们把所有前端请求分为两类，page类和api类，page类主要是返回html，api类返回json数据，所有的返回即使在异常情况下（大部分异常）也是标准的{"result": "","data": "","success": "","message": ""}，前端通过angularjs的拦截器功能，实现了全站的异常封装和交互，节约了很多代码
因为我们的遵循了从繁入简的设计思想，所以虽然因为实际情况妥协将回收模块，客服模块，调度模块进行了耦合，但大家都清楚系统未来演进，业务继续生长是一定会进行拆分的，所以我们在代码迭代中会刻意保持不同模块的独立性，领域模型不要过度耦合，跨模块调用统一采用基于bean的服务实现，关键编号保留分库分表位。这样后期如果必须进行拆分时，也会很高效。
...还有很多，一些细节想起来再加吧，这个项目已经交付好久了。
至此基本罗列完了我们对该项目的需求整理，分析以及系统设计的大致过程。
大家如果对其中的部分细节感兴趣，或者有异议，非常欢迎留言谈论批评指正，我会及时勘正补缺。
软件攻城狮
//我所经历的大数据平台发展史（三）：互联网时代 o 上篇http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02 编者按：本文是松子（李博源）的大数据平台发展史...
X399平台点睛之笔ZENITHEXTREME引爆性能狂潮 近期，X399平台的顶级性能浮出水面，各家媒体的全方位测试犹如一支强心剂，让PC玩家大呼过瘾。我们惊喜地发现，国内外各大科技媒体一致选用了ROGZENITH EXTREME这款主板。它是华硕目前最顶级的X399芯片...
//我所经历的大数据平台发展史（二）：非互//我所经历的大数据平台发展史（二）：非互联网时代 o 下篇http://www.infoq.com/cn/articles/the-development-history-of-big-//我所经历的大数据平台发展史（二）：非互联...
第一章1．设计现代OS的主要目标是什么？答：（1）有效性 （2）方便性 （3）可扩充性 （4）开放性2．OS的作用可表现在哪几个方面？答：（1）OS作为用户与计算机硬件系统之间的接口（2）OS作为计算机系统资源的管理者（3）OS实现了对计算机资源的抽象3．为什么说OS实现了...
图片发自简书App001 加入简书平台才两个月时间就碰到了很有趣的事情，一件事情是1月份去北京出差，结果在一个活动现场意外的碰到了刘淼老师和另一个写友，而且还通过刘淼老师结识了剽悍一只猫，你说这是不是机缘呀？这两个人可都是简书上的大咖呀，所以我觉得我非常的幸运。 第二件事情...
作为一只流浪的金毛犬，我本是拥有优裕的生活，家境还殷实，主人对我也不错，他时常带我去兜风，逛公园，泡温泉，还让我和其他漂亮的狗狗约会，当然了，这种机会只有在主人见他的女朋友的时候有，我知道，作为一只宠物，我不能奢求太多，这样我已经很满足了。 可就这样简单的生活过了没几年，我...
听说，是二胎暴涨的两年。 在我看来，的确是这样。我身边就有好多同事、同学，在在春节前后当上了二胎父母。一时间感觉满世界都是二胎宝宝。 以我这个资zhuang深bi的二胎爸爸的经验来看（因为本人在家里也是排行老二，就兄弟俩），通常二宝都会比较好带。因为一定有...
欧阳崇一就是欧阳德（年），崇一是他的字，他的号是南野，江西泰和人，官至礼部尚书。欧阳德为人敢于“谠言正论”，不避权贵，临危不惧。他服膺王守仁的“致良知”说，并以此重新解释《大学》“格物致知”的意旨。欧阳德是江右王学正传的主要代表人物之一，影响较大。他在发明...