【51CTO.com原创稿件】在WOT2016移动互联网技术峰会上，王庆友前1号店首席架构师兼独立技术顾问为我们讲述APP服务端的变化过程。王庆友老师从四个方面为我们讲述：架构历史和问题、最新服务端2.0架构、APP架构总结及架构本质的理解。
架构历史和问题
最初架构，可以称为0.1版本，架构本身非常简单了。首先有一个无线接口模块，统一对接APP的请求，内部是利用各个业务开发team提供架包完成业务逻辑返回结果。这个架构有两色，一个是集中式架构，另外是架包物理耦合。对于一开始提供一个简单的APP还是非常有利，但是后续弊端很明显，主要有两块：第一，这是物理架包耦合，各个业务team负责架包开发，开发完需要同步给服务端开发team，经常导致双方通讯出问题，导致架包版本不一致，出现各种各样的坑。第二，对服务端开发team也很有挑战，他拿到架包，架包太原始了，需要对架包在基础上做很多梳理整合，汇总数据，提供给客户端，相当要理解所有1号店的业务逻辑，这个挑战性非常大。
1.0架构，功能越来越多，对各个业务研发team，负责这个接口，一般情况下还是以PC端为主，不会提供单独应用实现无线功能，会在PC端Web系统提供简单的处理，无非还是HTTP请求，相当于在Web系统开了一个无线小窗口来满足APP的请求需要。这个架构对于提供业务功能还是很有利的，因为每个业务team非常熟悉本领域的业务逻辑，但是因为散带来后续一系列问题。第一个问题，紧耦合，虽然不是架包物理耦合，无线小窗口跟Web系统耦合在一起，有两块独立的需求。第二问题，每个业务team拿到接口以后，更多关注业务功能开发，通用功能不大会关注，无线也有自身的特点，需要一些通用功能开发，包括无线协议分装、安全、性能监控、日志等等。
最新服务端2.0架构
在2.0架构，无线端处理过程跟Web端处理过程，两个完全相互独立，以前无线总体上是依附于Web系统，现在是完全独立的。接下来具体介绍一下无线网关内部三个层的设计。每个具体功能又是相对独立的，分装成拦截器的形式，各个拦截器共同组成处理链，分为Inbound进来的处理链跟outbound出去的处理链。一个请求过来首先经过Inbound处理，再进行具体业务处理，又反过来进行outbound处理，这里业务处理不是属于通用层，放上去只是为了更好说明目的。如果一个拦截器处理完以后，产生一些结果，后续拦截器想利用这个结果，是通过统一上下文对象传递信息。
APP架构总结
路由层，根据无线请求过来的URL里有路径信息，转发到具体的适配器。适配层，定位是各个业务系统在无线前端代理，是起到代理的作用，是根据预处理过的、通用处理过的请求，转发到后端实际业务系统做进一步处理，主要是适配和转发目的。具体接口也是把参数清晰分为两类：一类是偏业务参数，一类是偏设备参数。在无线网关系统级功能在通用层得到很好的处理，业务逻辑也是通过适配器做代理，后续也是得到很好的处理。服务升降级，中心化对外提供服务，每个无线请求过来，是用Java线程，都会有线程去对应做相应的处理，这部分资源是共享的。
架构本质的理解
一个系统开始比较简单、比较清晰，随着功能越来越多，像机房一样布线越来越多，慢慢整个体系非常混乱，架构整个系统混乱度增加，慢慢失控了。在物理上热力学有个很著名的熵增加理论，一个分配系统如果人为不对它进行干预，自然情况下慢慢会从有序变成更加无序，它的熵不断增加，这个熵是衡量一个系统的无序度。这时就需要架构介入，对系统进行有序化重构，为这个系统建立一个秩序体系。在这个秩序体系里，每个模块、每个功能都有一个清晰的定位，都是有序的，通过这个架构改善，最终减少系统的熵，使系统能够不断进化。架构改造的手段其实很简单，就是分和合。分首先把大的系统打散，成一个具体的子系统或者模块，这个打散不能是随意的，一定要根据每个子系统模块、定位，根据定位才能找到边界，才能进行合理切割，每个模块或子系统内部是高内聚的，模块、系统之间是松耦合的。最终可以根据具体业务需求有机组合起来，打造一个有机的系统，如果需要一个大的业务创新，可以简单调整一下，重新整合，可以快速满足业务需要。
最后从分和合的角度，对服务端架构重新回顾一下。0.1架构是这个形状，很类似单体架构，我称之为形不散神散，形不散很好理解，神散是神比较散的，内部模块、子系统之间是非常紧密的耦合，如果想改一个地方就牵一发动全身，类似单体架构一样，神是比较散的。1.0架构，非常类似简单分布式架构，是直上直下烟囱型结构，这个称之为形散神也散。从单块来说还是有神的，端到端处理，但是总体上看神是比较散的，之间缺乏一个有机关联。2.0架构，有点类似于搭积木，这个称之为形散神不散，形散是很直观的，为什么说神不散?神体现在首先网关每一层有清晰的定位，各个层之间通过一致的数据格式、接口规范有机串接在一起，最后完成端到端的功能。具体对通用层，通过拦截器链把各个拦截器有机结合起来，从单个拦截器来看功能很散，但是总体来看每个拦截器是一环扣一环，形成一个有机的总体，共同完成一个系统级的处理，所以是有它的神，很类似SOA架构。特别是最近比较热门的微服务架构，微服务形肯定是很散的，但神散不散?微服务架构需要一个重点考量的地方，微服务一定要把系统核心灵魂体现出来，如果只是打造成一个服务，微服务反而是一点价值没有，整个系统变成形散神也散的系统。不管是0.1架构、1.0架构还是2.0架构，需要提供的功能都是那么多，是由业务本性属性决定，少不了。但是通过一个有效重新分和合有机组合起来，整个架构给系统建立一个很清晰的秩序，在这个秩序下每一块都有明确的定位。有序化带来的结果，系统开发成本、开发效率，系统可用性、系统可扩展性都大大提高，这是架构带来的价值。
本文作者：刘晓旭
来源：51CTO