精华内容
下载资源
问答
  • 在上一篇文章中主要讲了业务架构的基础部分,整体的业务架构还有一些其它点要考虑,如业务之间的彼此隔离、业务与技术 (平台) 的隔离、业务能力地图的可视化、业务 mock 能力、业务监控等,本篇文章主要讲述这些内容...

    上一篇文章中主要讲了业务架构的基础部分,整体的业务架构还有一些其它点要考虑,如业务之间的彼此隔离、业务与技术 (平台) 的隔离、业务能力地图的可视化、业务 mock 能力、业务监控等,本篇文章主要讲述这些内容。

    一、业务彼此隔离

    在较小的公司可能要体现这个没有对应的业务场景,但在大公司中,如果业务是平台型的,承接的业务方较多,业务方之间的需求还不一样时,就体现出了业务与业务之间的隔离。比如,优惠券业务是平台型业务,有多个业务线的业务方接入,它们的诉求也不尽相同:有的要实现业务线内不同用户角色的打通 (乘客、司机等)、业务线之间风控策略也不一样、优惠券发放规则也不一样…

    业务与业务的隔离需要有一个标识来唯一标志,阿里有的团队叫 bizId,在我们团队是通过 productId(业务线 Id) 来区分。标识说起来简单,但它只是第一步,隔离的表象就是通过业务线来区分。思考一个问题为什么要实现业务之间的彼此隔离?

    • 业务自身需求:这个很好理解,不同的业务有自己的特点。
    • 业务之间的互不影响:隔离的目的就是为了互不影响,将变化的东西缩小到业务线内,不可能改动一个业务线的需求,结果把其它业务线影响了。
    • 业务的可扩展性:平台型的业务有一个最大的特点是要较好地支持可扩展性,往大的方面讲,新接入一条业务线的改动有多大、往小的方面讲,对于某个业务线内的需求改动又是多大,比较好的状态就是具备可配置,稍微配置一下,一个新业务线就接入,这是我们最想看到的结果。

    通过 productId(业务线 Id) 这个唯一的业务身份串起整体业务,在业务处理过程中,可以知道这个业务线需要的具体业务策略和处理规则。

    img

    结论一:业务与业务的隔离体现了业务之间的变化和独立性,所以就产生了业务与技术 (平台) 的隔离

    二、业务与技术 (平台) 的隔离

    业务与技术 (平台) 的隔离体现了变与不变的关系,虽然这句话被很多人讲过,但不同的系统实现的策略不一样。平台型业务一般要解决 80% 以上的共性问题,20% 左右通过开放来实现。

    业务与技术 (平台) 的隔离不像业务与业务之间的隔离那样,两个业务之间没有交集,业务与技术 (平台) 之间是有交集的,这让人听起来有些蒙,下面细细分析。

    • 不同业务线之间有一条共性的业务流程:虽然不同的业务线产品之间有各自不同的点,但它们之间有一个明显共性的业务流程,这个业务流程是业务的生命周期,就好比类与对象之间的关系,本质是同一类事物,不同的对象好比不同的业务线产品,具体的实现上有些差异。在优惠券中,核心的业务流程就四个:建券、发券、用券、退券,不管什么业务线接入,它都遵守这条固定流程。

    • 业务变化的是子流程中的内容:不同业务线产品的不同之处体现在哪里?体现在业务细节上,这个是变化的,如业务的准入条件不一样、业务规则不一样、有的子流程中某一个处理步骤不需要…,这些是变化的部分,需要把变化的部分抽象出来并封装变化。所以,不变的是业务大流程,变化的是业务实现细节

    • 业务与技术 (平台) 的隔离理解的二重性:有些人理解业务与技术 (平台) 的隔离就是业务的实现不依赖于技术,比如数据要怎样存储?服务治理用什么框架?…这些说的是对的,它本身没有错。而我理解是有两重含义:一就是如上面所说的,业务的实现不依赖于具体技术,偏技术选型,这是常识;二是领域层的可扩展性,前 2 项已经说了业务的共性和变化,这个就是体现出应对变化的策略,尽管不同的系统有不同的具体实现,但总的原则是平台要能识别出这些变化,并能应对这些变化。

    业务与技术 (平台) 的隔离体现在共性和变化的隔离,把变化的部分告知平台、实现开放出来,所以说它们是有一定交集,这个交集就是应对变化的部分。它涉及到技术方面,所以在技术架构中会单独拿一篇来讲。

    img

    结论二:业务与技术 (平台) 的隔离主要体现在处理业务的变与不变

    三、业务能力地图

    我们有一个体会是开发和产品有时在谈一个需求时,开发用开发的语言、产品用产品的语言,两个很难统一,虽然通过领域建模可以统一认识,但是随着时间的推进,人员结构也在不断变化,如何快速熟悉业务、统一业务认识是一个问题。

    发现通过业务能力地图来表示业务流程,可以减少沟通、统一认识、可视化表示业务产品功能所经过的关键业务路径,这样一个新人进来通过这个业务能力地图就可以知道业务的主流程是什么,产品功能涉及到哪些业务子流程,针对一个需求,开发不需要看代码哪里要修改,很直观地在业务能力地图可以知道本次需求涉及到的改动点,从而提升整体效率。

    在做业务能力地图之前是有条件的,否则只是一家之言,有什么意思呢?就是业务已经进行了领域建模,业务产品和开发达成了统一的认识,业务的领域对象有哪些、业务的主流程、子流程有哪些、业务的准入条件、规则判断等,只有这些大家已经统一认识了之后,再通过技术手段把这些信息可视化表示出来就行,否则只会站在开发的角度来理解要表示哪些流程步骤。换言之,业务能力地图中所展示出的节点信息都是开发、产品统一的语言。

    业务能力地图是领域模型的进一步扩展和延伸,领域模型偏静态的表达领域对象和领域对象之间的关联关系;而业务能力地图是动态的表达业务执行流程是什么。领域模型是基础,业务能力地图是进一步的扩展,一个表达有什么,一个表达怎么做,一动一静,可以更好的理解业务和业务流程所涉及到的核心步骤。

    结论三:业务能力地图是在领域模型的基础之上进一步扩展,可视化地表达业务流程

    四、业务mock 能力

    业务mock 能力是指mock 用户数据方便排查问题,排查问题的第一步是重现问题,尤其是在端上,可能在某些条件下展示有问题,用测试数据又没有重现这个问题,如何来做呢?可以通过mock 用户的信息来展示数据,说白了就一句话偷天换月,在最底层的查询时,把用户信息置换掉。举个例子,用户在下单时发现有些优惠券没有展示在列表页中(实际上是有些优惠券不满足订单条件,如满减券、限门店使用等),用户向客服反映,客服再向技术支持人员反馈,技术支持人员再往具体的开发反馈,这个链路就很长了。如果客服同学使用这项mock 能力,完全可以通过mock 用户数据来当前的数据是怎么展示的,再看用户所有优惠券,对比优惠券的限制规则就能知道哪些优惠券不能使用,这样就可以快速响应用户问题。

    使用这个mock 能力时,有一点需要考虑的就是数据安全,并不是所有的行为都可以mock,一般来讲只有读场景下才能mock;还有一点需要注意的是全链路mock 范围,只有在指定的接口上才能mock,不能直接从导购链路一路往下mock,只会在最底层的业务接口上进行mock,否则全链路数据都被置换了。

    结论四:mock 主要方便问题重现和定位

    五、业务监控

    业务监控也是非常重要的一个环节,不同的公司用的方法也不尽相同,也要看业务规模和公司的实际情况,不可能要求所有的公司都使用大数据来分析。根据自己的经历谈谈这块。

    小公司直接统计业务数据表,比如之前做过金融,根据还款数据拆分成还款计划,还款计划再生成对应的还款订单,这里面的涉及到的业务数据就比较多,但能够很好地进行监控,当时根据业务数据状态、数量来判断业务是否已经处理完了,通过核对数据看今天的业务执行是不是正确的。这虽然很简单,通过写 SQL + 定时执行 shell 脚本就可以搞定,在业务的初创期它最简单,关键是提炼出监控的指标和维度。

    在大公司,通过日志采集、清洗、实时统计,可以看出当前业务的处理情况,有同比、环节的数据,如当前下单率是多少,通过监控这个指标可以看出业务是否正常,如果下单率明显下跌比较厉害,大概率是哪个链路上出了问题。

    通过业务监控大盘分别从不同的维度来监控业务运行状况,从而可以分析判断出当前业务是否受影响,帮助开发人员提前发现问题,这一块也涉及到稳定性方面,大公司是非常重视这一块的,阿里双 11 会专门成立稳定性小组,稳定压倒一切。

    结论五:没有业务监控的系统对业务的运行状况一无所知

    六、小结

    本篇文章是在上一篇文章的基础之上,对业务架构进一步补充,在平台型的业务中,着重注意业务与业务的隔离、业务与平台的隔离,实现最少的投入实现最大的业务价值。后面提到的业务能力地图、业务 mock 能力和业务监控是从工具层面上统一人员认识、提升沟通效率、快速发现、复现问题。接下来的系列就是技术架构了,从技术的角度解决常见的问题,如高并发、高可用、稳定性、高可扩展等。

    展开全文
  • 伴随着Docker技术的兴起,以及容器集群管理...但是,企业IT,尤其是非互联网传统企业,PaaS平台的构建与业务上云是一个长期的过程,绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就能完成的,IaaS年代是这样,P
    文/ 天云软件 技术总监 牛继宾 
    

    伴随着Docker技术的兴起,以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道,仿佛PaaS平台及其相关技术一下进入了黄金时期,各种各样的技术组合,各种各样的技术验证,以及伴随着容器相关的创业公司布道,仿佛只要有了PaaS平台及其相关的技术,就能解决一切的企业IT问题。但是,企业IT,尤其是非互联网传统企业,PaaS平台的构建与业务上云是一个长期的过程,绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就能完成的,IaaS年代是这样,PaaS年代也是这样。

    在互联网公司或者自研发型的应用,开发环境与部署运行环境非常的类似,这也是Docker或者容器相关技术在应用上的一个很大的优势(比如构建开发、测试、部署的DevOps流水线),但是在传统企业便不一定能行得通,比如某个企业的IT应用开发维护是外包的,标准软件需要采购、应用开发需要在应用开发商完成、硬件是另外的硬件提供商,到货后需要硬件系统集成、标准软件部署、应用开发部署调试,需要很多供货商来完成,往往以项目经理统筹完成,很难由一套DevOps之类的平台来解决所有问题。

    那么传统企业PaaS平台设计需要什么样的功能?上云时又需要进行如何改造?这是本文探讨的重点。

    一、传统企业的应用架构与应用分类

    屏幕快照 2016-06-16 上午9.53.36

    大家对这种架构耳熟能详,但也请做云计算或者容器技术的同事不要对这种架构嗤之以鼻,因为这种架构也包含很多对我们有学习借鉴意义的技术模块:

    • SAN存储:包括高、低、中不同的存储,存储中磁盘的RAID配置、存储池配置、存储的集群配置、存储的容灾备份、数据的热点迁移、数据的缓存、存储之间的SAN交换机配置(划分Zoning,连接主机)等都需要专业的存储工程师(衍生出来了很多的认证),这种存储可以做到高IOPS、低延迟、高可靠性,是目前大多数的分布式存储难以匹敌的,且目前存储厂商在SAN上也做到了虚拟化;
    • 主机:小型机、x86服务器,小型机以IBM小型机为例,小型机虚拟化比x86虚拟化出现的年代早了几十年,当时是硬分区技术,后来发展到逻辑分区+IO虚拟化,逻辑分区可以做到分配0.1个CPU的细粒度,同时也在2007年就推出了类似于容器的技术,做到了进程级别的隔离,但因为不开源、不方便打包、镜像管理没有Docker方便,最终只在少数客户处进行了部署使用;
    • DB:传统的数据库厂商比如Oracle为例,很早就推出了RAC技术,同时,2012年左右Oracle研发中心内部就开始使用Container技术搭建DB as a Service(这比我们目前大多数的Docker相关的创业公司还早);
    • APP:以IBM WebSphere为例,十年之前就有WAS集群的概念,可以部分做到横向扩展。

    传统企业这种架构统治了企业IT数十年之久,在大的行业,通常以商用中间件、商用DB、小型机、SAN存储部署。这种架构存在扩展性不足的问题,但是在传统企业架构中大量存在。

    我们部署一个IT系统,最终的目的是为了解决传统的问题,所谓把线下业务线上化,这些业务最终的服务对象是数据,而数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。

    当然还有其他的业务类型,比如银行或者运营商的每月出账系统,这种系统为也是一种批处理系统,但是实时性很强,跟Hadoop MR所谓的批处理不是一个概念,也不在一个层级。这种应用我们暂时不考虑。

    屏幕快照 2016-06-16 上午9.54.00

    OLTP,也叫联机事务处理(Online Transaction Processing)系统,表示事务性非常高的系统,一般都是高可用的在线系统,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。典型的OLTP系统有客户关系管理系统、电子商务系统、银行、证券等。

    要求:一致性、高可用性。

    OLAP,也叫联机分析处理(Online Analytical Processing)系统,有的时候也叫决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,考核的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。

    下面我们分别分析一下这两类应用的云化需求与云化的分析。

    注意:这些要求分析与要求是在Docker与各类容器管理平台火起来之前总结与做的,不是依据Docker或者容器相关技术的要求做的。所以,对我们跳出容器的惯性思维,构建一个适合传统企业的PaaS云平台有很强的指导意义。

    二、传统企业的应用云化改造需求

    (一)OLTP类应用云化的要求

    屏幕快照 2016-06-16 上午9.54.16

    云化关键点1:系统弹性伸缩

    通过应用与数据分离和集群化部署,实现系统快速扩容、处理能力灵活水平线性扩展、故障自动隔离。对于独立的应用主机可以进行灵活弹性伸缩。

    屏幕快照 2016-06-16 上午9.54.36

    弹性伸缩特点:

    1. 在线快速扩容:系统扩容操作低耗时、无数据迁移、服务不间断;
    2. 处理能力线性扩展:系统处理能力可以通过新增节点近线性提升,实现高吞吐、高并发处理能力,应对业务爆发式增长;
    3. 故障自动接管:集群可以自动发现故障节点并调整任务调度策略,在不影响处理的同时接管故障节点,保持系统高可用。

    云化关键点2:应用集群化部署

    将紧密耦合的大应用模块化拆分为多个模块化小应用,通过资源池提供系统资源的整体利用率,并将拆分后的子模块部署于资源池(后来我们搞Docker的称之为微服务化)。当硬件资源实施池化后,才具备了支撑应用的弹性伸缩,实现硬件的按需分配的基本需求,充分提高资源利用率。

    云化关键点3:通过数据分级分类实现应用与数据分离

    根据数据实时性、重要性、敏感性等因素,将数据分成数个级别,各个级别的数据对系统的作用、采用存储、保护方式也都有所不同。

    屏幕快照 2016-06-16 上午9.54.54

    通过对应用提供数据的透明访问,屏蔽数据的位置差异、数据分布差异、数据存储等差异:

    1. 位置无关性:数据在远程还是本地存储,对应用最好透明。
    2. 分布无关性:数据分布在多个数据节点,对应用透明。比如查询某个客户的所有相关数据,虽然同一个用户信息分布在多个数据节点上,但对应用来说就好像一个集中数据库进行查询。
    3. 存储无关性:数据存储在内存库、物理库(关系型数据库、NoSQL数据库)、File还是缓存等介质,对应用透明。

    云化关键点4:合理规划实现数据分布式部署

    对不同业务的数据、不同类型的数据进行有效规划部署。通过某种特定的条件,将存放在同一个数据库中的数据分散存放到多个数据库上,实现数据分布存储,通过路由规则路由访问特定的数据库。

    数据库拆分方式包括:

    • 垂直(纵向)拆分:将数据库表按业务、功能拆分到不同的数据库表,比如分为客户资料库、订单库、资源库、资料库等,这种方式多个数据库之间的表结构不同;目的是降低业务之间的影响,减少系统承载压力。
    • 水平(横向)拆分:将同一个表的数据进行分块保存到不同的数据表中,这些数据库中的表结构完全相同。

    拆分以后,带来的问题,需要做到:对外提供统一访问,对应用屏蔽数据访问复杂度。数据访问层提供数据互访能力,拆分访问合并返回。

    所以需要构建统一数据访问引擎,或者数据路由层(Data layer层)。开源的比如有Hibernate Shards、Ibatis-Sharding、淘宝TDDL等。

    云化关键点5:数据平台化

    数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整,将业务处理中的业务数据和状态数据与应用分离,实现应用的轻量化、无状态;构建统一的数据访问层,实现数据的共享访问。数据平台化是数据处理水平线性扩展的前提和基础。

    数据平台化特点:

    • 应用轻量化:缩短开发周期,提升新业务响应速度;
    • 应用无状态:实现应用的同质化,应用层处理能力的独立扩展,实现应用灵活调度和分配;
    • 数据共享访问:逐步实现数据集中访问,跨地市的流量共享、流量统付、流量转移业务能够更高效支撑。

    (二)OLAP型应用云化的需求

    首先看一下传统的数据仓库典型架构:

    屏幕快照 2016-06-16 上午9.55.11

    这种架构以处理结构化数据为主,基本部署于Oracle、小型机、SAN存储之上,扩展性不足,难以处理海量数据。大数据处理技术的兴起让这类应用的云化找到了思路。云化时总体推荐混搭架构,即采用多种技术架构建设大数据中心:

    1. 垂直混搭架构:

    屏幕快照 2016-06-16 上午9.55.23

    这种架构比较容易部署,但会形成多个相互独立的信息孤岛;未来缺乏可行的系统演进路;

    2. 水平混搭架构:

    屏幕快照 2016-06-16 上午9.55.37

    • 企业级数据云平台:逐渐实现企业内数据的统一存储,承载数据的加工计算;未来提供企业数据的统一存储和计算能力;
    • 数据仓库、集市和挖掘库:计算逐渐迁移到云平台实现轻载化;直接从云平台加载应用结果数据,实现上层应用的兼容性;
    • 流处理平台:实时计算结果存储到云数据平台,可通过能力开放平台的消息中间件直接供应用访问。

    OLAP云化关键点1:数据计算引擎开源化

    M/R计算引擎:用HDFS文件保证每一步计算结果,避免硬件故障导致重头执行。

    • 优点:可靠性高;
    • 缺点:数据处理任务是一系列M/R任务的串行执行,输入和输出都是HDFS文件,导致频繁的磁盘I/O,执行速度慢;
    • 局限性:原始单一的编程模型和数据结构,导致开发效率低,限制更多应用的产生。

    Spark计算引擎:RDD是分布式内存的抽象。

    • 优点:执行效率比起M/R提升100倍以上;提供丰富的操作算子增强编程能力,简化应用开发;
    • 缺点:对内存等资源要求高;可靠性不如M/R;
    • Yarn实现资源调度和分配:一个节点上可同时执行M/R和Spark任务,资源相互隔离、执行互不干扰。

    OLAP云化建设关键点2:数据集市云化建设

    建设现状:传统小机+Oracle数据库和新建的MPP数据库两种建设模式。

    • 演进策略一:用MPP数据库来取代小机+Oracle数据库;
    • 演进策略二:用数据云平台+开源MYSQL/PGSQL集群来代替小机+Oracle数据库。

    数据云平台完成所有的后台计算。

    屏幕快照 2016-06-16 上午9.55.50

    OLAP云化关键点3:数据ETL云化建设

    • 传输的实时化:支持MQ等分布式实时消息传输机制;
    • 基于内存的计算:数据不落地,避免海量数据的两次重复加载;
    • 计算的轻量化:清单级的过滤、排重、规则化,更多的计算任务由大数据存储和计算平台来完成;
    • 分布式并行执行:高可用性、分布式调度、资源分配;
    • 技术实现:Kafka+HDFS+MR/Spark。

    屏幕快照 2016-06-16 上午9.56.06

    三、基于容器的PaaS平台架构的构建

    我们提到了传统企业中两类核心的应用,并且在Docker流行之前便规划了一些云化的关键点,并形成了PaaS平台,使之运行于IaaS平台与Hadoop YARN集群之上。

    屏幕快照 2016-06-16 上午9.56.18

    基于此架构有以下几个主要问题:

    1. 可以实现应用编排与部署,但是编排的基础单元是虚拟机模板,模板比较重,而且镜像很难修改,编排、分发、运行、持续集成等都有很大的困难,因此构建在模板上的应用形成的服务很难用;
    2. 基于虚拟机的弹性伸缩相应时间也比较慢,我们尝试做过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能,发现弹性伸缩对业务的响应时间有一个偏差,这个偏差大约在十几分钟,在抢购、秒杀等业务中基本不可接受;
    3. 很难在企业内部形成一个统一的私有云集群来同时运行这两类业务,因此两个PAAS集群实际上是两个独立的集群,都是按照业务最高峰配置,存在资源浪费的现象,运维也是分开运维。

    Docker及其相关技术兴起之后,我们基于容器的相关生态圈技术,构建了新一代PaaS平台。

    屏幕快照 2016-06-16 上午9.56.37

    使用容器+容器镜像管理替代服务目录管理+虚拟机模板管理。

    在Instance PaaS(iPaaS)平台上除了基于Kubernetes的容器管理、镜像管理、应用管理等功能,还构建了如下子系统:

    • 日志子系统:基于ELK实现;
    • 计算子系统:集成OpenStack与自研的Skyform CMP;
    • 存储子系统:通过Cinder,支持ISCSI、NFS、Ceph三类存储,与IaaS打通;
    • 网络子系统:我们选用了Netron+OVS的SDN解决方案;
    • 监控子系统:通过Ceilometer+MongoDB进行实施数据的监控、Phoenix+Hadoop进行历史数据分析;
    • 用户交互子系统:基于Node.js开发。

    整体的PaaS平台构建基于Kubernetes、Hadoop、Spark on Mesos,构建完整的DCOS平台。

    需要说明的是,在传统企业在云平台还需要对接大量的系统,比如ITIL、4A/3A、人力资源系统、审计系统等,这些系统与云平台的接口集成不在本次讨论范围内。

    下面说一下基于以上的PaaS平台对传统应用云化关键点的解决。

    针对OLTP类应用云化的5个关键点的解决:

    1. 系统弹性伸缩:通过Kubernetes RC+service实现;
    2. 应用集群化部署:通过Mesos/Kubernetes构建x86集群,将应用分布式改造以后部署与集群;
    3. 通过数据分级分类实现应用与数据分离:通过Big data PaaS的HDFS服务与Instance PaaS的DB服务可以提供部分数据分级服务的基础,但是数据分级与存储,以及访问透明性未能完全实现,需要在业务层面进行适配;
    4. 合理规划实现数据分布式部署:通过在Instance PaaS提供数据库服务,以及开开源数据路由服务,实现,注:需要DBA规划数据的存储;
    5. 数据平台化:应用改造后即可实现。

    OLAP云化的3个关键点的解决:

    1. 数据计算引擎开源化:可由Bigdata PAAS直接提供MR、Spark服务;
    2. 数据集市云化建设:可由Instance PaaS平台提供开源MySQL+TDDL实现;
    3. 数据ETL云化建设:可由Instance PaaS提供Kafka、Big data PaaS提供MR、SPARK实现。

    四、PaaS平台问题及传统应用上云改造的一些注意点

    (一)基于Kubernetes、Hadoop、Spark on Mesos的问题

    这种调度实际上是两级的调度框架,Mesos本身只管资源(主要是CPU与MEM),提供offer给上层的调度框架使用。一级调度即Mesos层有两种调度模式:

    1. Mesos粗粒度,这种模式下,一旦一台机器(一个Node)分配给某个框架,其他框架便不能使用;
    2. Mesos细粒度,这种模式下,多个框架可以共享一台机器(一个Node)。

    粗粒度存在资源还是不能完全共享的问题,因此仍然有资源浪费的问题,细粒度模式可以改变这种问题,但是又带来新的问题:

    1. Mesos集群运行多种框架,包括Spark,也运行着很多Web、中间件、数据库等服务,但是Mesos不支持抢占,无法设置任务优先级,而Spark默认是贪婪模式,这样就会出现Spark运行时无法发布其他Web任务到Mesos集群上的情况。
    2. Hadoop与Spark在运行时,Shuffle阶段数据会交互写HDFS磁盘,这时网络资源会被大量占用(我们称之为东西向流量),导致Web服务基本不能响应(我们称之为南北向流量)。

    (二)多租户的问题

    目前多个框架之间每个都有自己的用户管理模式,默认情况下,如果多个框架之间有交叉使用,需要在多个框架之间租户互相打通,涉及到Mesos、Hadoop、Kubernetes的账号打通问题,需要开发独立的账户中心,并且完成同步。

    最后讨论一下应用上云时的考虑点,并给出一个例子:

    1. 应用最好无状态,无状态化的应用天生适合上云。这时服务的注册于发现、应用的弹性伸缩完全交给云平台来做,比如Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC;
    2. 已经集群化的应用组件部署相对困难,比如基于PaaS平台发布单个实例的Redis容器,但是发布Redis集群就比较困难,苦难就困难在Redis集群中的节点需要相互通信,而容器如果重启或者IP发生变化都会对集群造成影响;
    3. 服务注册与发现如果应用本身提供了,PaaS平台的服务注册与发现功能便不能使用,不能两套服务注册与发现同时使用。

    这里给出一个应用上云部署的例子:

    屏幕快照 2016-06-16 上午9.56.53

    上图左边是某传统企业电商应用最初架构,Web部署于一台高配置x86服务器、APP部署于一台中端小型机、DB部署于一台中端小型机,右边是初步进行了改造后的架构,即迁移到PaaS平台之前应用已经做了模块化与集群化的初步改造:

    1. 前台用负载均衡将流量引入到三个Web节点中,每个Web节点部署于x86服务器,Session集中存在Redis集群(无状态化改造,交互用HTTP+JSON短连接);
    2. APP层也通过Redis集中存放状态信息,做到了无状态化,每个APP节点部署于三台x86服务器;
    3. Web与APP在流量大的时候可以做到手动扩容,但是需要配置固定的IP,APP服务(提供给)的注册发现是基于ZooKeeper完成(应用自己来完成服务注册于发现);
    4. DB层做了主从数据库,部署与x86服务器。

    该应用里面还用到了Kafka,用来做数据总线,也采取了集群化部署。

    屏幕快照 2016-06-16 上午9.57.06

    针对目前的现状,如上图,应用迁移到PaaS平台需要做三方面的工作:

    1. 完成Web层的服务注册与发现,在此基础上实现web层的自动扩缩容,此处基于Kubernetes的ingress service(一个改造后的Nginx,运行在一个Kubernetes的POD里面)实现软负载+RC控制节点伸缩实现(每个Web部署于一个pod);
    2. APP层的自动扩缩容,由于已经完成了基于ZooKeeper的服务注册于发现,所以只需APP层能够弹性伸缩部署即可;此处基于RC控制节点伸缩实现;
    3. DB层由于运行稳定,暂时不做PaaS化但是,基于访问路由做到分布式部署。

    剩余一个问题需要探讨,Redis集群、ZooKeeper集群、Kafka集群(用作消息总线)要不要做PaaS化?如何做?

    首先回答一个问题,Redis、Zookeeper、Kafka等集群PaaS化(容器化)的难点在哪儿?

    主要是这些集群节点之间的互相通信与数据传输即东西向流量,要求这些节点之间的IP配置需要固定IP,而且重新启动以后相应的配置信息不能改变。容器自身的启动、网络配置比较动态化,对需要固定的集群配置而言是一个挑战。

    比如大多数的PaaS平台提供单个实例的Redis缓存服务不是问题,但是提供任意配置的Redis集群便不支持。我们经过前期的测试,实现了容器平台下的此类应用的集群化部署,以ZooKeeper为例:

    屏幕快照 2016-06-16 上午9.57.22

    ZooKeeper自身部署要求:

    1. ZooKeeper client依赖固定ZooKeeper server IP来完成服务;
    2. ZooKeeper server配置(所有成员IP必须固定);
    3. 至少3个独立节点;

    解决方案(基于Kubernetes):

    1. Client通过固定3个service IP连接ZooKeeper server;
    2. 构建3个单POD的RC;
    3. 配置DeamonSet,指定ZooKeeper的POD所启动运行的主机;
    4. ZooKeeper自身配置使用Service DNS name;
    5. 存储进行持久化。

    最后,需要说明的是,应用上云后一个很重要因素,PaaS平台(Docker为基础的构建),稳定性与可靠性也是至关重要的,我们在部署迁移应用时,每次都会针对应用做较为详细的测试,测试案例包括:

    • 无负载的POD并发测试;
    • 频繁创建带业务的POD及其稳定性;
    • 业务的并发性测试;
    • 不同业务的IO并发性能测试;
    • 容器间网络性能测试;
    • 几类常见的数据库性能测试;
    • Nginx集群性能测试;
    • Kubernetes Rc机制测试;
    • Docker对MEM资源限制能力的测试;
    • Docker对进程数量限制能力的测试;

    等等。这些测试方面供大家参考,具体测试方法与步骤可针对应用自行设计,不在这里具体分享。

    Q&A

    Q:在你的新一代PaaS平台中,我怎么对公司的很多个不同的应用做不同的集群,有些集群偏向于大量的IO占用,有些集群偏向于大量的网络占用,有些集群偏向于大量的内存占用,并且启用的集群间还有通信和交互,针对这些不均衡现象该如何处理?

    A:所以PaaS平台硬件资源会针对不同应用去做区分,在企业私有云建设时,需要对应用进行梳理,将不同的应用分类,底层采取相应集群支撑,比如计算密集型、IO密集型等,同时综合考虑波峰波谷与业务特性进行配置。

    Q:公司有很多Web系统,每一个Web系统都有自己的存储、数据库,所以如果融入PaaS平台的话,首先第一点软硬件问题如何做到全部满足,其次就是就算把我的DB层整合迁徙到你的PaaS的DB层,我是不是还要做其它方面的投入,比如开发成本等等,还有就是DB的兼容性是不是会有问题?

    A:Web层我们推荐做无状态化,且要做应用与数据分离,session信息集中存放。DB迁移到PaaS层是一个比较慎重的过程,PaaS层优先考虑开源数据库。如果原先是MySQL基于PaaS平台也提供的MySQL数据库服务,那么开发成本基本比较小,只需考虑版本问题。

    Q:请问MySQL部署数据应用能承载多大数据量,响应速度如何?

    A:我们一个项目中,采用读写分离的MySQL架构,几千万的数据表,及时查询没问题,这也要看硬件配置与数据索引的建立等。

    Q:有些传统公司,有些软件设备是以序列号安装使用的,所以这一块融入PaaS平台是不是不太可能?

    A:比较困难,另外还有一个问题是License限制的问题,在弹性架构中也比较难。

    Q:请问架构改造会不会导致应用要重新开发?

    A:会,从IOE架构到x86架构,从x86物理机到虚拟机到Docker,应用需要以越来越小的模块化分布式部署,也就是说逐步向微服务化过渡。

    Q:为什么Kubernetes和Mesos要一起用呢,考虑点在哪里?

    A:针对单个应用Docker化,我们开始的选型定位在Kubernetes,主要考虑了POD的应用场景更类似虚拟机,另外Kubernetes的模块比较丰富,像负载均衡、服务发现等已经成熟,后来用Mesos是因为需要把大数据之类的应用进行整合。需要Kubernetes/Spark on Mesos。

    Q:开发周期过长或者客户开发能力弱会导致整个架构流产 有配套的应用改造方案吗?

    A:对传统企业而言,一开始就搭建一个大而全PaaS方案是不现实的,我们推荐从某一个典型应用做起。我们针对交易性应用、分布式应用、批处理应用等应用都有配套改造方案。

    Q:Mesos使用集中式存储和分布式存储效率上有什么不同吗?

    A:这个看应用,集中式存储在集群中应用时,如果针对单一与应用划分Volume,性能会好一些,如果是分布式应用,比如MR类的应用,分布式存储反而会好。

    Q:容器弹性伸缩策略具体怎么考虑的,CPU?

    A:CPU、内存、IO、用户连接数等都可以作为弹性伸缩的策略依据。

    展开全文
  • 资讯数据业务设计思路内容简介资讯、知识库数据流程图问诊业务流程图 内容简介 由于之前很多人问我数据是如何展示到可视化界面的,本篇解答目前项目中数据的全部流程。 资讯、知识库数据流程图 问诊业务流程图 .....

    试读内容
    「基于Python技术的智慧中医商业项目」项目文章目录
    「基于Python技术的智慧中医商业项目」中医问诊学习,开发原理理论基础
    「基于Django的家庭健康数字服务平台」产品设计&技术应用 V2.0

    全部文章内容都在项目文章目录里可以找到,全部项目集网站开发、中医诊疗系统、数据采集、数据分析、人工智能应用、数据化运营等综合性的内容于一体,有兴趣的朋友请在此关注,如果觉得内容对你有帮助请转发给更多的朋友。

    内容简介

    本文内容为该项目V1.0版本的内容。

    公网采集的数据以及后台编辑的数据是如何展示到可视化界面的,本篇解答目前项目中数据的全部流程。

    数据流程

    1.资讯、知识库数据流程图

    展开全文
  • 支付业务的数据库设计

    千次阅读 2016-09-04 07:59:51
    一、数据 数据库中的数据是整个核心逻辑的载体说在,所有的记账逻辑、以及与支付前台交互的数据都是在这里 进行记录。现就主要的进行简要说明。不同的第三方支付其数据名称肯定也不同,这里的名称仅作...

    一、数据表

    数据库中的数据表是整个核心逻辑的载体说在,所有的记账逻辑、以及与支付前台交互的数据都是在这里 进行记录。现就主要的表进行简要说明。不同的第三方支付其数据表名称肯定也不同,这里的表名称仅作参考

    • gTransLog表: 支付网关交易流水表,所有通过网关的交易全部都会在此表中写入数据。
    • tAccounts表: 用户的账户数据记录表,在第三方系统中其记录着用户的账上资金。
    • tAccountLog表: 用于记录账户的自己流水情况,所有对tAccounts表的资金变动都会在流水表中进行记录
    • tBankPaymentInfo表: 上传对账文件后,解析对账文件生成的表
    • tBankcardInfo表: 用于存储用户或者商户所绑定银行卡的信息,包括银行名称、卡号等
    • tChannelConfig表: 渠道配置表,用于配置商户与不同渠道的对应关系,比如接入支付宝或者招商银行
    • tFreeze表: 冻结表,当tAccounts表中的资金有事先冻结的情况下,比如说基金赎回等会向tFreezes表中插入数据
    • tPayments表: 付款表,记录账户付款相关信息
    • tReceivables表: 收款表,记录收款信息
    • tPaymentChannel表: 商户付款渠道的相关信息
    • tRefundChannel表: 商户退款屠刀的相关信息
    • tRollLog表: 业务流水表
    • tTrans表: 交易表,只要是交易,资金有变化,是商户与用户交互的过程
    • tTransLog表: 交易流水表,记录交易流水的相关信息
    • tTransCashBack: 记录银行账号退款的相关信息
    • tBankPayReconFile表:上传对账文件后,解析对账文件生成的表
    • tReconcilationPaySucc表:对账成功后写入的表
    • tReconcilationPayFail表:对账失败后写入的表
    • tAccountSystemayPaymentInfo表:付款内部数据收集表

    二、数据表分析

    在第一部分对其中后台记账系统的数据表中大致进行了一下说明,但是其中也会有一些需要注意的点, 这才测试中分出关键。现在就每一个表进行详细的分析一下。

    1、gTransLog表:该表是所有网关交易都要登记的表,从支付前台传入的数据首先经过gTransLog表进行 网关登记和注册,然后再进行其他记账。在表中有内部交易单号,用于查取交易数据;有returnCode用户存放银行返回 的数据;有状态标志用于查询交易的最终状态。很多时候,支付前端的请求都是直接查取网关表来进行某些交易逻辑判断。

    2、tAccounts表:该表是账户数据记录表,记录着用户账上的资金。可以联系一下支付宝,就相当于个人的支付宝账户 里面的余额。不同的记账系统对账户的区分也不一样,可能有的账户系统中只用商户账户存在,有的则允许个人和商户都存在。该 表中的账户除了较为重要的Balance Amount外,还有几点需要注意:

    • 账户的冻结金额
    • 账户的子类型,有些时候需要关注是主账户还是次级账户
    • 账户的科目类型,是资产账户还是负债账户,这在记录账户流水的时候很有用
    • 账户的状态,可用还是失效

    3、tAccountLog表: 该表是用来记录资金账户流水变化,并记录相关交易单号以及金额。在表中会有标志记录这次的资金流动情况 是借记还是贷记,这在核对账户的资金流动上很重要,难免出错。

    4、tBankPaymentInfo表:这个表在对账的时候使用,关于对账相关逻辑在下一章情景支付中进行讲述。这个表是付款对账表,当然与之 相对的是收款对账表,在此仅以付款对账表进行讲述。将对账文件进行解析,获取文件中数据,来成生成此表。将在外部对账时使用。

    5、tChannelConfig表:该表是渠道配置表,主要是商户使用。该表中配置了商户以及此商户所接入的渠道,比如支付宝或者某银行。可以 从现实生活中去理解此逻辑,在某商户进行购物时并不是每一个商户都对某家银行支持,说的也是这个道理。

    6、tFreezes表:该表为冻结表,当有交易发生资金冻结的情况时,都会向这个表中写入数据;而当这个某些资金解冻后,也将该冻结表中的 状态改为解冻。并不是所有的交易在金额变动之前都会去事先冻结金额,对于实时性交易来说,账户的钱是会被实时扣除。账户资金出现冻结的情况 出现在基金申购、优惠券消费等为数不多的场景中。

    7、tPayments表: 该表为付款表,这里的付款是从商户的角度来说的,对于用户来说就是收款。初次涉及账户逻辑时很容易将这逻辑搞混,这个表使用 再向用户打钱的时候才会被用到。比如在基金赎回的场景中,就会向这个表中插入数据,通过表中的状态,就可以判断其向用户打钱有没有成功,对于没有成功、 的情形又会涉及到退票的情形,这在下一章讨论。

    8、tReceivables表: 该表为收款表。这里的收款也是对商户而言,对用户而言则是付款。比如用户在进行购物的时候,用户是付款,商户是收款,那么此时 就会向此表中插入数据,其表中也存有state字段用来表示用户付款有没有成功。只要是涉及用户的资金进入第三方系统,此表都会有收款数据写入。

    9、tPaymentChannel表:此表为付款渠道表,如果从字面意思进行理解便可知道,这个是付款时的渠道。不管是商户还是用户其相关的付款渠道信息都是在此 配置,如果在这个表中将渠道置为无效,则在支付前端看不到此渠道。

    10、tRefundChannel表:此表是退款渠道配置表,可以类比付款渠道配置表进行理解。

    11、tTrans表:该表是交易表,核心点在与交易,交易必须有买和卖,只有这样才能完成交易。此时就涉及一个易被忽视的问题,比如向用户向自己钱包充值, 这个阶段只是收钱,并没有存在交易,所以在这个场景下并不会向该表中写入数据。在一般的交易中,可查看表中的状态来判断此交易的状态,是等待付款、付款完成 、付款失败、已清算。支付前端也时刻通过这个表来进行其他联接查询操作。

    12、tTransLog表:该表为交易流水表,对tTans表的变化都会在tTransLog中进行记录,这在后续查询交易异常情况下,比较有帮助作用

    13、tTransCashBack表:该表为现金退款表,当用户通过银行卡支付并成功扣款后,这个时候如果发起退款那么要这个表中插入数据。有一个情况要注意,这个表中的 数据只涉及银行退款,比如在组合消费的时候,可能有优惠券的金额。那么由于优惠券过期而发生退款时,银行卡退款部分写入tTransCashBack表中。

    14、tBankPayReconFile表:这个表中的数据为解析银行付款对账文件而来,其数据来源于银行。这个数据表为付款文件对账表,与之相对的是收款银行文件对账表,虽然 在这里没有将其列出,但是其业务逻辑思想是相通的。

    15、tReconcilationPaySucc表:对账数据的结果存放处,对账的结果又对平和对差的区别。具体在这里不做讲解,对平的数据放入此表中,而对差的数据放入Fail表中。

    16、tAccountSystemayPaymentInfo:这个表为付款信息收集表,也是内部对账后的结果表。与之相对的是收款信息收集表。

    展开全文
  • 电商平台-用户设计

    千次阅读 2018-07-11 11:07:34
    说明:由于该系统属于B2B平台,不设计到B2C的架构。 角色分析:买家与卖家. 由于买家与卖家所填写的资料都不一样,需要建立两站进行维护,比如:buyer,seller.这样进行数据库的解耦,任何一方的变动都互不影响,...
  • 营销业务规划重要性 一个完整的营销体系规划对于后续营销活动的策划,设计,管理,开发提供了很多帮助。从活动的实现角度来看,很难 做到一套营销系统支持所有类型的活动,但是我们可以分析多个活动的共性,从而抽象...
  • 电商平台-订单设计

    万次阅读 2018-07-10 09:53:51
    买家可以在张三家买茄子,李四家买萝卜,王五家买白菜,赵六家买猪肉等那么买家就应该有个订单主,我们称为订单,同时还有 上面所说的具体的订单明细,清楚的查看自己买了什么菜,多少元一斤,买了多少斤等。...
  • 软件设计业务逻辑层设计

    千次阅读 2016-07-15 16:19:53
    业务逻辑层(Business Logic ...它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain )逻辑有关,很多时候,我们也将业务逻辑层称为领域层。
  • 电商平台的数据结构设计

    千次阅读 2020-04-15 20:34:59
    数据结构设计1. 系统功能2. 2.1 用户mmall_user2.2 收货地址mmall_shipping2.3 商品mmall_product2.4 商品类别mmall_category2.5 购物车mmall_cart2.6 订单 mmall_order`2.7 订单明细 mmall_order...
  • 对于其它业务类型的平台,则估计会有其它形式的优惠,比如赠送三个VIP会员等等。 范围,无非就是: 整单 指定品类或特定品类(临时的活动分类,比如夏季新品特卖) ...
  • 数据表设计原则

    千次阅读 2014-11-06 09:56:10
    1)不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库之间的关联应尽可能减少,如果不同组件间的需要外键关联也...
  • 监控平台架构设计

    万次阅读 2014-05-29 23:31:56
    监控平台架构设计
  • 业务流程管理模型优化设计

    千次阅读 2015-07-01 08:21:40
    在需求的驱动下,对业务流程管理模型进行优化,分析业务、表单、工作流三者关系,给出优化的设计方案。
  • (五)购物商城数据库设计-用户表设计

    万次阅读 多人点赞 2018-06-20 22:05:41
    今天我们来讲下用户设计,首先是用户 用户(member_info) --- id 手机号 登录密码 邮箱 昵称 头像url 注册时间 默认收货地址id 接着应该有收货地址 用户收货地址(member_shopping_address) --- ...
  • 实时大数据平台设计与实现

    千次阅读 2019-01-12 16:24:38
    实时大数据平台设计与实现 什么是实时大数据平台 实时大数据平台和离线大数据平台还是有区别的,更强调数据的实时性.具体的架构,具体的代码该怎么写,模块怎么去构建,各个系统之间怎么去组织协调,都需要根据对应的...
  • 商城 商品模块 数据库 表设计

    万次阅读 多人点赞 2017-05-12 23:30:04
    要实现一个商城,对于商品模块中的数据库表设计不懂,主要是:相同类别的产品的产品参数相同,不同类别的不同,这里就不懂要怎么设计了,所以上网找几篇博客了解什么是SPUSKUARPU PHP商城 商品模块 数据库 表设计...
  • 表设计思路

    千次阅读 2016-04-17 10:48:37
    大数据量表的设计思路 Renhao 2011/4/7 ...大设计同系统其他设计一样,也需要遵从以下几个基本原则:  全面性:设计能够支撑与其相关的所有业务和数据承载,而非基于某一个功能点,更多需要从宏
  • 消息平台架构设计

    万次阅读 2017-10-14 18:04:32
    消息平台架构设计 一.消息平台的应用场景及难点 1.解决什么业务问题: a.端到云的实时上报 b.云到端的是实时推送 c.端到端的聊天消息 2.难点: a.APP无线环境下消息的可达性 b.通用性,平台实现尽量与业务解耦 二....
  • 智能家居云平台设计

    万次阅读 2019-04-09 16:39:07
    智能家居云平台设计 摘要 智能家居是未来家居的发展方向,其利用先进的网络技术、计算机技术和无线通信技术等将家居中的各种电子电气设备连接起来,统一管理、远程监控和资源共享,实现了高效、便利的生活环境。近...
  • 互联网安全架构平台设计

    千次阅读 2018-07-16 17:33:18
    彻底分析根据不同的业务场景,分析如何彻底防御 Token 伪造请求 2.信息加密与密钥管理 详细:单向散列、对称加密、非对称加密、密钥管理等,详细谈到各种加密算法优缺点及应用场景。 3.互联网 API 接口安全设计 ...
  • 在阿里云生态日,袋鼠云首席架构师正风分享了《新零售业务中台设计及实践》。他从行业背景及建设目标、业务中台的理念、技术体系与建议、产品体系与建议、案例分享五个方面进行了分享。在分享中,他主要介绍了客户...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 银行业务系统设计特点概述

    千次阅读 2012-07-18 11:43:25
    为了使系统具有更强的兼容性和可扩展性,系统应设计成开放式的网络业务系统。在开放系统环境OSE(Open System Environment)中所采用的规范是一种国际标准,与厂家无关,它允许不同厂家的计算机硬件产品和软件系统...
  • 云计算平台构建与实验设计

    万次阅读 多人点赞 2016-07-31 12:54:06
    通过构建一个云计算平台,并利用这个平台设计云计算实验,将结果与普通的电脑计算比较两者的差别,感受云计算的优越性能,从而对物联网有更深刻的体验与认识。 二、作业内容及要求  能够按照课程设计任务书按照相应...
  • 分布式架构设计之电商平台

    万次阅读 多人点赞 2016-10-15 16:23:43
    何为软件架构?不同人的答案会有所不同,而我...那么,接下来就以本人实际工作中的电商平台为例,进行说明电商平台架构设计,因为不同行业产品系统不同业务不同,而催生的系统软件的实现要求及架构设计就不同了! 
  • [产品设计]如何绘制业务流程图(下)

    万次阅读 2017-02-08 15:50:09
    细究起来,除了懒,原因其实有好几条:这一年半来的工作都是围绕数据平台建设,不是很通用,没法举例。虽然自己一直画页面流程图,但是说实话属于偏方多一些,按直觉行事,要总结出一两条可通用的“规则”比较难
  • 我对支付平台架构设计的一些思考

    千次阅读 多人点赞 2019-06-04 08:05:00
    我在前一家公司的第一个任务是开发统一支付平台,由于公司的业务需求,需要接入多个第三方支付,之前公司的支付都是散落在各个项目中,及其不利于支付的管理,于是聚合三方支付,统一支付平台的任务就落在我手上,...
  • 开发平台之组织架构设计

    千次阅读 2017-04-16 11:37:22
    设计而不接实际业务之气,设计的再好仍是空谈。 –王小七 需求1、组织架构除了法人组织架构外,还需要业务型的架构。—多维度组织架构2、集团发展迅猛,组织架构调整频繁,想看往年某个时间点的组织架构。—组织...
  • 【话费充值平台】话费充值平台接口设计

    千次阅读 热门讨论 2018-09-04 17:34:07
    预计做三个系统:接口平台业务处理中心,后台管理。 接口平台 需求 代理商通过约定的接口协议调用接口平台进行提单,接口平台需要对请求方做验证并且生成唯一订单号返回给代理商,代理商可以通过平台返回...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 374,180
精华内容 149,672
关键字:

业务平台表设计