文明网站建设情况报告,收款网站怎么建设,成都专业建设网站,研发项目流程八个阶段大家好#xff0c;我是易安#xff01; 早期2013年的时候#xff0c;随着智能设备的普及和移动互联网的发展#xff0c;移动端逐渐成为用户的新入口#xff0c;各个电商平台都开始聚焦移动端App#xff0c;如今经历了10年的发展#xff0c;很多电商APP早已经没入历史的洪… 大家好我是易安 早期2013年的时候随着智能设备的普及和移动互联网的发展移动端逐渐成为用户的新入口各个电商平台都开始聚焦移动端App如今经历了10年的发展很多电商APP早已经没入历史的洪流中但是一些则顺利的发展壮大起来。今天我们以国内某个电商APP为例带你一起探索下电商APP服务端的架构演变历程。 V1.0架构 我们先来看看早期的1.0版本具体的架构如下图所示 这个架构比较简单App的服务端整体上就一个应用由移动团队来维护所有对外接口服务端内部有很多Jar包比如商品搜索、商品详情、购物车等等这些Jar包包含了各个业务线的业务逻辑及数据库访问它们由各个业务线的开发者负责提供。 你可以看到这个1.0版本的服务端实际上就是一个单体应用只是对外的接口和内部Jar包分别由不同的团队来提供这个架构的优点和缺点同样都非常明显。 它的优点是简单方便。App前端的团队只需要对接后端的一个移动团队就可以了然后移动团队通过现成的Jar包封装各个业务线的功能。至于这些Jar包业务线团队也无需额外去开发。 为什么呢我们知道早期的电商平台都是先有PC端应用再推AppApp最开始的功能大多是从已有的PC端平移过来的。因此这些Jar包直接从PC端应用里拿过来就可以了如果Jar包版本有更新由业务线团队直接同步给移动团队即可。 那这个架构设计是不是很完美啊当然不是不知道你发现了没有其实这里也存在了很多问题。 第一个问题移动服务端对Jar包的紧密依赖 移动团队负责对外接口但他们非常依赖业务团队提供的Jar包来实现业务逻辑这是一种物理上的紧耦合依赖关系。 如果业务团队根据PC端的需求修改了应用代码后Jar包也会随之修改。那么在实践中经常会出现这样的情况业务团队很多时候要么忘了同步新的Jar包给移动团队要么是新的Jar包调整了类的接口导致了App服务端的功能有问题或者直接不可用。 第二个问题移动团队的职责过分复杂 服务端为App提供的是粗粒度接口而业务团队的Jar包提供的是细粒度的接口。 因此移动团队在Jar包的基础上还需要做很多的业务逻辑聚合很多时候这些逻辑还跨多个业务线导致移动团队对所有业务逻辑都要深入了解。相信你也知道这是很难做到的。 第三个问题团队并行开发困难 由于移动团队和业务团队是通过物理Jar包进行集成的移动团队直接受业务团队的代码影响就导致了团队之间并行开发困难一次大的App升级经常需要2~3个月的时间。过了一段时间当移动端的功能已经初步具备就需要针对移动自身的特点去组织功能并能够快速上线这些新功能。那么这种单体架构加物理Jar包耦合的方式就成为App进一步发展的瓶颈。 接下来我们就看下系统是如何通过架构升级来解决这个问题的。 V2.0架构 整体架构如下图所示 对于各个业务团队来说他们走向了前台每个团队负责各个业务线的App接口。他们一般采取这样的做法一方面他们以Web应用的方式为PC端浏览器提供访问另一方面针对移动端的访问需求他们在Web应用里面增加了一些REST接口直接供App访问。在这里移动接口和Web应用在同一个工程里开发作为同一个应用进行部署和运行。 这里你可以看到这实际上就是一种 分布式的系统架构每块业务由不同的团队负责可以很好地支持团队之间的并行开发同时移动接口和PC端共享底层业务逻辑有助于快速把PC端的功能完整地复制到App端。 这样 通过V2.0架构的升级业务线团队的生产力就被完全释放了App的功能也就快速丰富起来了。 但这种方式也带来了一系列的问题我们具体说下。 首先是移动端和PC端互相干扰的问题。 你可以看到在同一个业务线内部移动接口和Web应用物理上是绑定在一起的。很多时候PC端的代码修改会影响到移动接口而Web应用的发布也会导致移动接口被动地被发布如果PC端出现功能问题也会影响到移动接口的可用性。反过来也是一样的移动接口的需求变化会影响到PC端的功能。 我们知道当移动端发展到了一定程度它需要和PC端有不同的功能和用户体验但这种紧耦合的方式导致了相互之间产生很多不必要的干扰对系统的功能和稳定性都带来了负面影响。 其次是重复开发的问题。 移动接口除了要给App端提供业务数据还需要考虑一系列系统级的功能比如说安全验证、日志记录、性能监控等等每个移动接口都需要这些通用功能。 那现在由于App前端是和后端直连的这就意味着每个后端系统都需要独自去支持这些系统级的功能导致了各个后端系统重复开发。一旦这些通用需求发生了变化比如说我们要对传输数据进行压缩那么所有的后端系统都需要同步调整这样不但工作量很大而且也给项目管理也带来了很大的挑战。 最后是稳定性的问题。 在这里基于这种直连方式只要一个后端系统出问题就会直接影响到App的可用性使得App整体上非常的脆弱。 之所以会出现以上这些问题它的根本原因在于在App端直接照搬了PC端的做法没有针对移动端自身的特点去做架构设计。 我们知道当App发展到一个成熟阶段时无论是业务功能还是非业务性功能和PC端都是不同的。所以在架构设计上我们必须能够支持它们各自不同的特点根据这个思路App服务端架构V3.0版本因此诞生。 V3.0架构 在V3.0版本中服务端架构包含了两个大的升级。 首先对每个业务线的服务端进行拆分让App接口和PC端接口各自在物理上独立但它们共享核心的业务逻辑。 拆分后的架构如下图所示 这样拆分的结果是原来大的服务端变成了3个应用包括一个App端接口应用一个PC端Web应用还有一个核心业务逻辑服务3个部分都是独立维护和部署的。 除此之外架构改造还考虑了移动端自身的特点。 一方面每个移动端接口需要调用对应的后台服务进行业务逻辑处理这个是个性化的每个接口的处理逻辑都不一样另一方面每个移动端接口都需要进行系统级的功能处理比如前面所说的安全验证、接口监控等这个是共性的每个接口的处理方式都是一样的。 那么在架构上就需要把共性的系统级功能进行集中处理把个性化的业务功能进行分散处理。 最后结合服务端的应用拆分以及对移动接口本身的改造落地了服务端V3.0架构。 如下图所示 在这里App前端会通过 移动网关 来访问服务端接口。这里的网关主要就是负责处理通用的系统级功能包括通信协议适配、安全、监控、日志等等网关处理完之后会通过接口路由模块转发请求到内部的各个业务服务比如搜索服务、详情页服务、购物车服务等等。 对于PC端浏览器来说它直接访问对应的Web应用如搜索应用、详情页应用等然后这些应用也是访问同样的内部服务。 现在你已经了解了V3.0版本的整体架构设计接下来我们就深入移动网关去具体了解下它的内部实现机制。 移动网关的内部实现 在图中你可以看到整个移动网关分为三层自上而下分别是通用层、接口路由层、适配层接下来我们逐一分析。 通用层 首先是通用层它负责所有系统级功能的处理比如通讯协议适配、安全、监控、日志等等这些功能统一由网关的通用层进行预处理避免了各个业务线的重复开发。 在具体实现时每个通用功能的处理逻辑都会封装成一个拦截器这些拦截器遵循统一的接口定义并且拦截器都是可配置的。当有外部请求过来网关会依次调用这些拦截器完成各个系统级功能的处理。 这个拦截器接口的定义如下 Object filter(Object input)throws Exception 接口路由层 接下来是接口路由层。移动端请求经过通用层的预处理之后将会进一步分发给后端的业务适配器进行处理。 在配置文件里对接口请求的URL和业务适配器进行映射接口路由层的分发逻辑就是根据请求中的URL在配置文件里找到对应的适配器然后把请求交给适配器进行后续的处理。 配置文件的具体内容如下所示 www.website.com/search SearchAdapterwww.website.com/detail DetailAdapter 服务适配层 最后是服务适配层。我们知道外部接口的请求格式往往和内部服务接口的格式是不一样的。外部接口是HTTPJSON格式内部服务是Hessian二进制格式。 适配器首先用来解决内外部接口的适配除此之外适配器还可以根据需要对多个内部服务做业务聚合这样可以对App前端提供粗粒度的接口服务减少远程网络的调用次数。 这些适配器遵循统一的接口定义 Object adapter(Object input)throws Exception 这些适配器物理上是Jar包的形式由各个业务线研发团队提供所有的适配器会集中部署在网关而网关本身可以支持多实例的部署通过水平扩展的方式提升服务端的处理能力。 现在你已经很清楚了V3.0架构的实现细节接下来我们就深入看下这次架构升级达到了什么样的实际效果。 架构的实际效果 首先App端和PC端彻底独立了。在上面的图中我们可以看到App前端和PC端浏览器是完全对等的PC端浏览器有自己的服务端App前端也有自己的服务端在这里移动网关就充当App服务端的角色。 在这个架构下两个服务端都可以针对自身的特点独立开发独立部署无论在逻辑层面还是物理层面都实现了彻底解耦。我们知道一开始App是依附于PC端而现在它终于可以独立地发展了。 其次通过架构改造实现了核心业务的复用。这里我们把核心的业务逻辑从Web应用中剥离出来变成了共享的服务。在服务设计时我们不再区分PC端还是移动端而是从业务本身出发提供一套通用的接口同时供PC端和移动端调用从而实现了底层业务逻辑的复用。 还有这个架构强化了系统级功能。原来通用的系统级功能由各个团队各自去提供很多团队要么不提供要么实现的方式不一样现在的系统级功能是由集中式的移动网关统一来提供我们就可以很方便地强化这些系统级功能。 举个例子我们可以把通信协议由HTTP升级为更安全的HTTPS当后端服务有问题时也可以通过网关进行事先的数据缓存直接返回给App前端。比如说商品的详情数据就很适合这样的处理。 所以有了移动网关整个App的可用性、稳定性和安全性都得到了大幅度的提升。 最后团队分工也更明确了。在这里移动团队主要负责移动网关包括网关本身和各种过滤器的维护他们可以针对移动端的特点做各种系统级功能的优化而业务团队主要负责各自的业务逻辑包括适配器和底层服务。移动团队和业务团队通过明确的适配接口进行协作相互不影响。 我们可以看到V3.0在V2.0分布式架构的基础上通过服务化改造实现了基础业务的复用同时通过移动网关落地系统级功能实现了系统的平台化改造。 总的改造结果就是解放了业务线提升了系统的稳定性使得移动端可以做大做强。 总结 今天我分享了常见电商App服务端架构改造的演变案例。在这个例子中架构经历了单体架构到分布式架构再到SOA架构的变化过程并且通过移动网关的方式一定程度上实现了平台化。 本文由 mdnice 多平台发布
