云应用 移动云平台的基础架构之旅：云应用

作者:马

背景

目前10后可以在手机键盘上打飞一样的字，60后可以从容抖微信。移动互联网可谓炙手可热。随着智能手机的快速发展，手机APP作为登录移动互联网最便捷的方式，守卫着移动互联网的入口。如今，这种软件越来越受到人们的青睐。在没有大量资金的情况下，移动APP是中小企业的好选择。对于个人和企业来说，移动APP已经成为创业和发展的必备工具。移动互联网APP的开发面临着项目周期、资源投入、推广等诸多问题。，但对个人来说就更不鼓励了。

传统移动开发技术解决方案:

难题

1.终端移动平台太多了:安卓、IOS、Windows Phone、微信...不同平台之间存在版本差异，这对开发和调试来说是一场噩梦。没有强大的资金支持，很难实现统一覆盖。

2.开发成本:招人难，找对的更难，成本高，移动开发门槛是障碍

3.捡芝麻丢西瓜:企业把精力投入到自己不擅长的领域，尤其是个人，不是一件好事。

4.全站点解决方案:一个优秀的APP，除了核心业务，还需要其他优秀的组件，比如推送、用户行为分析、营销活动、数据统计等等。

5.运维难点:要保证APP稳定可靠的运行，运维是必不可少的一部分，而这些任务需要专业的运维团队来做。这也增加了企业的负担。

现在是反击的时代。为了帮助企业和个人拥有自己的无门槛应用，云应用平台应运而生。

云应用平台是在公司现有共享云服务基础上，整合不同行业模块，集APP生成、运营、分析、自动化运维于一体的服务。用户只需要关心自己的业务，完全摆脱以上所有问题。

用户可以结合自己想要的模块，点击生成APP，生成自己想要的不同平台的APP，包括Android、IOS、微官网、PC官网。

有待解决的问题

1.差异化服务。由于是面向多租户的服务，不同应用产生的流量可能相差很大，所以系统应该能够实现服务隔离和横向扩展。

2.数据隔离和扩展。为了保证数据安全，每个APP都会有一个独立的DB，数据只能由自己的APP访问，防止了数据黑客攻击，保证了数据安全。对于数据量大的应用，DB可以支持无限扩展。

3.快速部署和自动运行维护。

4.服务监控。由于服务分布在集群中的不同机器上，因此必须能够监控所有租户服务的运行状况，确保服务的高可用性，并能够横向扩展。

5.支持服务和数据的迁移

可以独立运行的1.0

因为云应用平台需要支持不同的行业，业务会越来越复杂。项目业务层按模块划分，不同模块组合，满足行业需求。

架构第一版遵循两个原则:一是以业务实现为目标，尽快做出产品原型。因为公司云平台已经有很多可以直接使用的基础中间件了，比如:推送、FAQ & amp；发行、支付、即时通讯&社会化等。现在，我们只需要关注云应用业务。二是快速响应产品需求，引导产品研发。很多场景和游戏一定要有助于产品的实现，速度要很快，迭代。

主要技术堆栈

Vert.x对大多数人来说可能有点陌生。是一个基于netty的异步架构，和node.js很像，基础架构一直用Vert.x，整个团队都很熟悉Vert.x，也踩过。现有的微服务可以通过Verx-Rpc直接访问。在使用Vert.x的时候，最大的感受就是不能写同步代码，否则会阻塞，使服务不可用，所以我们的服务都是异步写的。因为是轻量级、高性能的JVM应用平台，支持多语言开发，其简单的类actor机制可以帮助脱离直接基于多线程的编程，自然支持分布式，这将是未来服务扩展的自然之事。

主流的Hibernate或者IBATIS不用于ORM，使用少数的JOOQ。与其他ORM相比，JOQ非常轻量级，提供了强大的DSL来访问数据库，灵活易用，其代码非常接近sql。

JOOQ运行时模式映射对多租户应用有很好的支持，可以方便的为每个租户分配独立的DB。

另一个重要原因是JOOQ已经完全集成了Java8的Stream API，酷！！。函数式编程具有表现力和通用性。它是数据和数据流处理的核心。Java开发人员现在懂函数式编程，大家都用过SQL。想象一下，使用SQL来声明表源，将数据转换成新的元组流，然后要么将它们作为派生表提供给其他更高级别的SQL语句，要么将它们交给您的应用程序进行处理。

下面是一个典型的Java代码

有了JOOQ、Java 8和Streams API，就可以编写一个功能强大的数据转换API，简单易懂。

建筑特色

架构特性分为优点和缺点。

优点:

1.简单，易于实施，无需额外的基础支持

2.有利于业务功能的快速实现

3.服务都是从Docker Container开始的，可以实现快速发布和部署

缺点:

1.不同租户的应用无法隔离，所有应用使用同一个Container，会带来应用之间相互影响、服务不稳定的风险。

2.缺乏服务健康检查。

3.运维成本太高。

1.0的架构是一个简单的Web系统。负载平衡使用Nignx，这在租户级别没有详细说明。业务系统以代码模块的形式组织各种业务，是一个简单的Web系统，后面直接挂着数据库，比如商品、订单、会员、客服等等。可以看出我们的基本架构是外部HTTP。当时一个两人的小团队开发了各种业务，我们认为只能用最简单粗暴的方式实现，业务也能很快实现。在当时，流量不是第一重要的问题，也不是最重要的矛盾。

现阶段总结三点。第一，技术来源于业务，推动业务发展，进而推动技术向前发展。他们是一种相互影响、相互促进的关系。与商业一起发展的技术是至关重要的。第二，成熟简单的技术是最适合的，这个想法一直贯穿始终。不要给人看事物复杂的形态，保持头脑简单，不要去想这么复杂的事情。第三，要尽可能考虑自己能遇到的场景，这样以后架构升级就不会很被动了。如你所见，最初的架构等于没有架构，但这种形式是此时最符合业务需求的，可以快速迭代，非常方便上线。

多租户2.0

在MaxWon1.0时代，我们的重点更多的是业务的实现。随着用户的增长，性能和稳定性的问题逐渐浮出水面。作为多租户应用系统，系统不稳定，非常致命。用2.0解决这些问题迫在眉睫。

有待解决的问题

首先要解决的是服务分离。有两种方案:

1.每个租户APP都有自己的服务容器，解决了租户之间的相互影响。但大部分APP接入点可能很小，甚至是僵尸应用。Docker容器虽然使用的资源很少，但是大量的非活动应用仍然浪费了太多的系统资源，资源利用率低。

2.根据租客的真实到访情况，分成不同的小组。普通规模的应用或者僵尸应用共享同一套容器，一些中等规模的应用使用一套容器，数据流量大的应用独占同一套容器，所以资源利用率会很高。缺点是普通规模和中等规模的应用服务之间还是会有影响。因为这两个尺度的数据访问会少很多，所以慢查询降低整个系统速度的可能性很小。

通过比较上述两种方案的优缺点，最终基于实际考虑选择了第二种方案。所以需要能够随时监控某个APP的数据流量，当某个APP的流量快速上升时，可以随时独立提供服务，最大限度的防止租户相互影响造成的服务抖动。

服务监控采用心跳检测。每个服务容器公开一组健康检查接口。监测系统定期检查所有服务的健康状况。如果它由于某种原因被杀死，它将重启相应的容器并产生警报。

数据存储分离采用同样的思路。对于Mongo，潘多拉本身支持根据不同App数据分而治之。Mysql代理采用自主开发的喀尔刻组件，可以实现不同App数据的隔离。AWS ELB用于解决喀尔刻的负载平衡和高可用性。

2.0采用了服务和数据分离的思想，现在回头看也不复杂，代码农民很熟悉。如果你的产品功能不多，迭代也不快，可以放慢速度，停一会儿专心重构。但是对于MaxWon来说，这个版本的迭代就像换炮一样，符合大多数应用场景。这种重新配置对于业务迭代快、在线时间紧的系统来说也是一个很大的挑战。

优势

1.继承了原1.0的特点并保留了它的优点

2.解决了数据和服务的隔离和扩展问题

3.为不同的租户提供差异化服务

4.增加了服务监控和检查

码头工人建造和出版

使用docker构建可以完美解决环境冲突的问题，也可以方便快速部署和扩展。

有了spotify docker-maven-plugin插件，根据项目中预先定义的DockerFile，可以很容易地将项目打包成一个可执行的docker Image，并推入到生产环境中。

$ mvn干净部署-dpushiimage-Pcn

易于使用的中间件

九头蛇:九头蛇，古希腊和神话的形象，是一种传说中的九头蛇，为守护者守卫门户。这里，Hydra作为MaxWon的API网关，管理来自不同端的请求，并根据请求的来源将它们转发到相应的服务容器组。同时，它还管理和监控容器状态和服务的动态扩展。

喀尔刻:一个能在希腊神话制造幻觉的女巫。这里用它来比喻一个可以为Mysql服务创建代理的项目。它可以实现不同租户之间的数据隔离，过滤非法和有毒的sql语句，保证数据隐私和安全。

潘多拉:访问MongoDB的基本组件，提供同步和异步接口。Pandora的核心功能是实现资源限制和数据库访问的路由策略，为数据库的平滑动态扩展和迁移提供可靠支持。感兴趣的可以参考同事写的MONGO集群设计

总结

没有生意谈建筑就是扯淡。用技术手段提高工作效率是好事。不要陷入其中。而是产品是否解决了用户的问题，而不是你自己的问题。对于MaxWon这种快速迭代的系统，系统也会考虑更多的业务场景，体积会越来越大，难题也会越来越多，做好优化的准备。

系统要尽量保持简单，技术架构选择建议是寻找当前最短路径，然后进行持续优化迭代。一口吃掉一个大胖子是不可能的。

不要把代码写死。

同一系列的:

文章来自www.36dsj.com 36大数据，微信号大树巨36，36大数据是一个专注于大数据创业、大数据技术与分析、大数据业务与应用的网站。分享大数据干货教程和大数据应用案例，提供大数据分析工具和数据下载，解决大数据产业链中的创业、技术、分析、商务、应用等问题，为大数据产业链中的数据行业公司和员工提供支持和服务。

途经:CSDN

结束。