精华内容
下载资源
问答
  • 如何拆分微服务架构?拆分粒度多大比较合适?本章内容从问题开始,循序渐进,带领读者逐步深入微服务架构的各个角落。 1.1 微服务架构的起源 2005年,Peter Rodgers博士在云端运算博览会上提出的微Web服务(Micro-...

    王启军,云原生技术架构专家,曾任当当架构师,主导电商平台架构设计,包括订单、支付、价格、库存、物流等。曾就职于搜狐,负责手机微博的研发。十余年的技术历练,也曾作为技术负责人带领过近百人的团队。公众号“奔跑中的蜗牛”的作者

    1 微服务架构

    微服务架构是Cloud Native的重要组成部分,微服务架构给我们带来收益的同时,也会带来副作用,我们应该在什么阶段采用微服务架构?如何拆分微服务架构?拆分粒度多大比较合适?本章内容从问题开始,循序渐进,带领读者逐步深入微服务架构的各个角落。

    1.1 微服务架构的起源

    2005年,Peter Rodgers博士在云端运算博览会上提出的微Web服务(Micro-Web-Service),将程序设计成细粒度的服务(Granular Services),以作为Microsoft下一阶段的软件架构,其核心思想是让服务由类似Unix管道的存取方式使用,而且复杂的服务背后是使用简单URI来开放界面,任何服务都能被开放(exposed)。这个设计在HP的实验室被实现,具有改变复杂软件系统的强大力量。

    2014年,Martin Fowler与James Lewis共同提出了微服务的概念,定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统,每个服务都以一个独立的进程的方式运行,每个服务与其他服务使用轻量级(通常是HTTP API)通信机制,这些服务是围绕业务功能构建的,可以通过全自动部署机制独立部署,同时服务会使用最小规模的集中管理(例如Docker)能力,服务可以用不同的编程语言和数据库。

    实际上,微服务的诞生绝非偶然,敏捷开发帮助我们减少浪费,快速反馈,以用户体验为目标;持续交付促使我们更快、更可靠、更频繁地改进软件;基础设施即代码(Infrastructure As Code)帮助我们简化环境的管理,这些都是推动微服务诞生的重要因素。如果没有这些基础,微服务架构在展现魅力的同时,可能由于各种问题导致最终失败。

    从SOA架构到服务化架构、再到微服务架构,是一个逐步演进的过程,Amazon被认为是微服务的鼻祖,2015年我曾经接触过一个Amazon的工程师,他并不是特别了解微服务这个名词,直到看完Martin Fowler关于微服务的文章,才发现自己一直在做的就是微服务架构。可以说微服务架构并不是什么技术创新,而是开发过程发展到一个阶段对技术架构的要求,是在实践中不断摸索而来,每个公司所信奉的架构思想有相同之处,但是也不尽相同。这种化繁为简的拆分方式,不只在技术上带来突破,更带来了很多潜在的价值,如关注点分离、沟通效率提升、快速演进、快速交付、快速反馈等。

    1.2 为什么采用微服务架构

    1.2.1 单体架构VS微服务架构

    就像很难用一个绝对的方式去判断架构好坏一样,在大多数场景下,我们也很难从一个外部的视角去判断服务拆分粒度的合理性,需要对上下文非常了解才能做出一个好决策。例如,团队规模多大,代码规模多大,有没有平台化,有没有工具链,是否需要持续交付,团队文化如何等。因此,一个外部的架构师是很难在短时间内将架构规划合理的,这需要一个过程,当真正了解这一切之后,不断权衡,最终确定。在划分之前,有必要参考表2-1,综合各方面的情况,最终做出决策。

    表2-1 单体架构VS微服务架构

    因素

    单体架构

    微服务架构

    说明

    交付速度

    较慢

    较快

    服务拆分后,各个服务可以独立并行开发、测试、部署,交付效率提升,产品的更新速度会更快,用户体验更好。代码规模越大,微服务的优势越明显

    故障隔离范围

    线程级

    进程级

    服务独立运行,通过进程的方式隔离,使故障范围得到有效控制、架构变得更简单可靠。根据业务的重要程度划分服务,把核心的业务划分为独立的服务,这样可以从数据库到服务,保持有效的故障隔离,进而保持稳定

    整体可用性

    较低

    更高

    微服务架构由于故障范围得到有效隔离,整体可用性更高,降低一点故障对整体的影响

    架构持续演进

    困难

    简单

    由于微服务的粒度更小,架构演进的影响面就更小。不存在大规模重构导致的各种问题。微服务架构对架构演进更友好

    沟通效率

    业界普遍认为团队规模越大,沟通效率越低,微服务架构按业务构建全功能团队,把权利下放,不会出现决策瓶颈点,降低沟通规模,提升沟通效率

    技术栈选择

    受限

    灵活

    如果某个业务需要独立的技术栈,可以通过服务划分,接口集成的方式实现。例如搜索,技术栈、专业细分领域都不相同,通常采用独立的服务实现

    可扩展性

    受限

    灵活

    微服务架构可以根据服务对资源的要求以服务为粒度扩展,符合AKF扩展立方体中的Y轴扩展,而单体架构只能整体扩展,只能做到AKF扩展立方体中的X轴扩展

    可重用性

    微服务架构可以实现以服务为粒度通过接口共享重用

    实现业务复杂性分解难度

    困难

    容易

    微服务架构通过将业务分解为更多的服务,业务边界更清晰,更容易把一个复杂的问题分解为简单的小问题

    产品创新复杂度

    困难

    容易

    微服务架构以服务为粒度独立演进,团队有更多的自主决策权,更多的试错机会,更利于创新

    一致性实现成本

    服务划分后,如果服务A同时调用服务B和服务C,如何保证同时成功或失败?单体架构下的单库事务变成了分布式事务问题

    时延

    服务划分后,调用次数增加,响应时间必然升高,吞吐量降低,如何弥补

    资源成本

    吞吐量的下降意味着要增加更多的资源,对于交付型项目,特别是小规模部署的场景下,是比较致命的

    关联查询复杂度

    简单

    复杂

    微服务架构的一个非常明显的特征就是一个服务所拥有的数据只能通过这个服务的API来访问。通过这种方式来解耦,这样就会带来查询问题。以前通过join就可以满足要求,现在如果需要跨多个服务集成查询就会非常麻烦

    远程调用

    不涉及

    涉及

    微服务存在更多的远程调用,需要额外考虑序列化、通信协议、数据压缩、服务间的负载均衡、容错等问题

    服务治理

    不涉及

    涉及

    由于服务数量变多,微服务架构需要额外考虑服务的注册发现、依赖关系、治理等问题

    对开发人员的要求

    微服务架构更复杂,开发人员端到端负责,既要考虑接口定义,又要考虑数据库设计,对开发人员的水平要求更高

    对工具的依赖

    较低

    较高

    微服务架构中服务的数量较多,使用工具的效果更明显,依赖程度更高

    运维复杂度

    微服务架构中服务的数量较多,对服务的监控、健康检查要求更高,整体运维复杂度更高

    1.2.2 什么时候开始微服务架构

    产品初期,应该以单体架构优先。面对一个新的领域,对业务的理解很难在开始阶段就比较清晰,往往是经过一段时间之后,才能逐步稳定。很多时候,从一个已有的单体架构中逐步划分服务,要比一开始就构建微服务简单得多。另外,在资源受限的情况下,采用微服务架构风险较大,很多优势无法体现,性能上的劣势反而会比较明显。

    单体、组件化、微服务架构成本趋势,如图2-1所示。当业务复杂度达到一定程度后,微服务架构消耗的成本才会体现优势,并不是所有的场景都适合采用微服务架构,服务的划分应逐步进行,持续演进。产品初期,业务复杂度不高的时候,应该尽量采用单体架构。

    图2-1 单体、组件化、微服务架构成本趋势

    下面内容摘自Martin Fowler的博客。

    As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

    1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up.

    2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

    简单翻译如下。

    当我听到关于使用微服务架构的故事的时候,我注意到了一种通用的模式。

    1. 几乎所有成功的微服务架构都是从一个巨大的单体架构开始的,并且由于太大而被拆分为微服务架构。

    2. 几乎所有我听说过从一开始就构建为微服务架构的故事,最终都遇到了巨大的麻烦。

    在服务划分之前,应该保证基础设施及公共基础服务已经准备完毕,可以通过监控快速定位故障,通过工具自动化部署、管理服务,通过服务化框架降低服务开发的复杂度,通过灰度发布提升可用性,通过资源调度服务快速申请、释放资源,通过弹性伸缩快速扩展应用。

    1.2.3 如何决定微服务架构的拆分粒度

    微服务架构中的微字,并不代表足够小,应该解释为合适。但是合适过于含糊,每个人理解的合适都不尽相同。实际上,有时候对于一个对业务理解不够深入,对团队情况又不是很了解的人,根本无权协助确定服务的粒度。况且,就算本团队的架构师,也很难确定粒度。随着业务发展,开发人员水平的提升,粒度可能会发生变化。这是一个磨合的过程,一个不断演进的过程,没有绝对的对与错。

    如果实在找不到合适的依据,可以参考表2-2,决策占比是从通用的角度考虑,并不适用所有的情况,某些公司认为团队规模是决定性的,也有些公司认为架构演进是决定性的,还有些公司认为交付速度是决定性的,找到那个你认为的决定性因素,去做合理的拆分即可。

    表2-2 微服务拆分粒度决策参考表

    序号

    因素

    决策占比

    说明

    1

    团队规模

    50%

    当团队规模变大,会出现决策瓶颈点,即所有的决策都要依赖于某个会议或某个人,没有人愿意承担责任,效率十分低下

    2

    交付速度要求

    30%

    毫无疑问,拆分粒度越小,交付时受到的约束越小,速度就越快

    3

    其他

    20%

    例如,对占用资源的要求、对性能的要求、对一致性的要求、对架构演进速度的要求、对创新速度的要求

    1.3 微服务设计原则

    在微服务架构的设计过程中,我们应该遵循哪些原则?以下原则在微服务架构中经常被提起,遵循这些原则能够让我们少走弯路。

    垂直划分优先原则

    应该根据业务领域对服务进行垂直划分,因为水平划分服务可能会导致如下问题。

    • 调用次数更多导致性能大幅下降。

    • 实现一个功能要跨越更多服务,沟通成本升高。

    垂直划分服务可以以最简单的方式缓解上述问题,并且可以让团队从上至下关注业务实现,端到端负责,持续改进。图2-2简单描述了一个按业务领域垂直划分的微服务架构示例,在业务垂直方向切分服务,通过API Gateway聚合内容。

    图2-2 垂直划分服务

    持续演进原则

    服务数量快速增长带来架构复杂度急剧升高,开发、测试、运维等环节很难快速适应,会导致故障率大幅增加,可用性降低,非必要情况,应逐步划分,持续演进,避免服务数量的爆炸性增长,这等同于灰度发布的效果,先拿出几个不太重要的功能拆分出一个服务做试验,如果出现故障,则可以减少故障的影响范围。另外,除了业务服务数量的增加,还需要准备持续交付的工具、微服务框架等,加强监控。

    服务自治、接口隔离原则

    尽量消除对其他服务的强依赖,这样可以降低沟通成本,提升服务稳定性。服务通过标准的接口隔离,隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行,以服务为单位持续交付。

    直接访问对方的数据库会造成一定的耦合性,应该尽量避免。

    自动化驱动原则

    部署与运维的成本会随着服务的增多呈指数级增长,每个服务都需要部署、监控、日志分析等运维工作,成本会显著提升。在服务划分之前,应该首先构建自动化的工具及环境。开发人员应该以自动化为驱动力,简化服务在创建、开发、测试、部署、运维上的重复性工作,通过工具实现更可靠的操作。避免微服务数量增多带来的开发、管理复杂度问题。自动化可以从多个方面节省时间、提升效率,它可以快速跟踪整个交付过程并实时向所有参与者报告这个过程,赋予参与者责任感和成就感,如研发过程中,推行持续集成的文化就特别重要,而持续集成所依赖的工具就是一种自动化的体现。

    很多互联网公司都遵循“一切皆自动化”的原则,特别是存在跨地域的研发模式时,使用自动化工具将是至关重要的,如开源的协作模式。

    1.4 微服务架构实施的先决条件

    不提倡从一开始就建立微服务架构的原因之一是没有做好准备,下面我们来看一下建立微服务架构前,需要从哪些方面做准备。

    1.4.1 研发环境和流程上的转变

    在实施微服务架构之前,我们要准备相关的环境和流程,可以简单地通过以下几方面建立基本的条件。

    自动化工具链

    微服务架构的一大优势是快速交付,快速交付不只是体现在服务的粒度更小,可以独立交付,还体现在整个流程更快速,微服务架构基于自动化的工具链,以流水线交付的方式串联整个DevOps流程,小团队可以基于服务独立开发、测试、部署、运维。传统的交付周期以月为单位,而微服务架构的交付周期能做到以天为单位,如果按照传统的开发模式是无法满足要求的。

    微服务框架

    微服务框架可以封装、抽象分布式场景下的一些常用能力,例如负载均衡、服务注册发现、容错、远程通信等能力,可以让开发人员快速开发出高质量的服务,在采用微服务架构之前,应该先进行微服务框架的选型,试用。

    快速申请资源

    如果以天为单位进行交付,就必须能够快速申请资源。基础设施即代码可通过编程的方式管理虚拟机或容器,免去了手动配置、更新各个硬件的需要,这就使得基础设施极具弹性,能够快速、高效、准确的进行重复性操作,开发人员使用同一套配置或代码,就可部署并管理成千上万台物理机。基础设施即代码能够得到更快的速度、更低的成本和更可靠的环境。用代码定义服务器配置意味着在众多服务器之间有绝对的一致性,容易形成标准化。手动调整配置往往会有一些微妙的差异,难以追溯和调试,并且会导致许多诡异的问题。

    故障发现反馈机制

    当服务数量增多,频繁交付的时候,故障次数可能会大幅上升,我们需要通过全面的监控发现故障,及时处理并发出报警。当生产环境出现问题的时候,需要将故障进行分级,评估影响面,并分配给相应的架构师或者开发人员,开发人员需要不断更新故障的状态,便于管理者、客服、销售人员等问题相关人了解进度,以提供更好的用户体验。

    研发流程上的转变

    需要重新组建团队,以服务为核心,按照业务领域划分全功能团队,改变原有的研发流程、决策机制。例如,倡导敏捷文化,快速迭代,做更多的自动化测试,加强Code Review,给团队更多的自主决策权等,可以参考本书第九章和第十章。

    1.4.2 拆分前先做好解耦

    解耦这个词汇来源于数学,是指使含有多个变量的数学方程变成能够用单个变量表示的方程组,即变量不再同时共同直接影响一个方程的结果,从而简化分析计算。

    在软件世界里,解耦强调的是每个单元可以独立变化,尽量减少外界的影响。说白了也就是,如果把Memcache换成Redis,那么需要多少工作量,涉及的修改面有多大。但是,解耦也会带来工作量的增加,架构或者代码变得复杂等问题。例如很多人会假设把Oracle换成MySQL,Memcache换成Redis,但是在实际的情况中,并不是所有的业务发展速度都有这么快,如果能预料到短期将发生变化,为什么不直接使用MySQL呢?通常这是一个伪命题。如果在未来几年后才发生变化,那么现在去做相应的适配,这不符合敏捷开发的哲学思想,也不是一个高效率的思路。

    在转向微服务架构之前,业务服务存在状态、数据库中存在触发器和存储过程、服务之间绕过接口调用等问题是我们首先要解决的。

    状态外置

    无状态(Statelessness)指的是服务内部变量值的存储。有状态的服务伸缩起来非常复杂,可以通过将服务的状态外置到数据库、分布式缓存中,使服务变成无状态。通常业界用牲畜来比喻无状态,用宠物来比喻有状态,宠物是需要呵护的,是有名字的,不能被轻易替换的,而牲畜是没有名字的,只生产肉和奶,死掉一个,用新的来替换即可。所以,我们期望服务可以做到无状态,可以被轻易地替换掉。

    但是,无状态不代表状态消失了,只是把状态转移到分布式缓存和数据库中了,业务服务伸缩的时候,还是要考虑分布式缓存和数据库所能承受的压力限制。那为什么还要外置呢?因为一方面即使不外置到数据库,数据库也存在状态,另一方面,这样可以把复杂度抽象到统一的位置,便于集中处理。例如,服务端的Session信息可以放到分布式缓存中,这一设计方法既可以让业务服务在一定范围内(分布式缓存的上限)伸缩时不受状态的限制,又可以把复杂度抽象到特定的位置,让专业领域开发人员统一做有状态的伸缩。虽然绝大多数服务都可以状态外置,但是并不是所有的业务服务都能设计成无状态,例如客户端与服务端的长连接,这种状态很难外置。

    以下三种常见的状态需要和业务服务拆分开来,否则扩展性将受到很大限制。

    (1)定时任务。

    因为大多数任务不能重复触发,轻则重复做无用功(幂等的情况下),重则会导致不一致。例如从A表中把数据迁移到B表中,如果在两个服务中同时处理,没有一个协调器的话,会导致重复拉取。所以,需要把定时任务从业务服务中提取出来,通过分布式任务调度统一协调。

    (2)本地存储。

    在本地存储文件也是比较常见的,当有多个实例的时候,要么全部同步一遍,要么需要根据用户路由到同一个实例,并且在伸缩的过程中,需要迁移。

    (3)本地缓存。

    某些业务会将数据存放在本地做缓存,例如Session数据,如果要去掉本地缓存,则可以通过分布式缓存和Cookie解决业务服务带状态的问题。

    当然,本地缓存也有适用的业务场景,不能一概而论。

    去触发器、存储过程

    触发器、存储过程在系统规模比较小的时候,的确非常简单实用。但是,随着业务的发展,业务服务比较容易扩展,数据库通常变成了伸缩的瓶颈,许多方案都是为了平衡数据库的压力,触发器、存储过程可能会带来如下问题。

    • 整体的伸缩受到数据库的限制,因为触发器、存储过程难以扩展。

    • 当存在水平分表的时候,可能无法满足需求。

    • 如果触发器、存储过程过多,则会导致运维复杂度升高。

    解决方案通常是通过外部的业务服务或者定时任务替换触发器及存储过程。

    通过接口隔离

    直接访问其他服务的数据库,如图2-3所示。CRM直接调用OA的数据库,没有通过接口调用,当我们对CRM进行微服务架构拆分之前,需要先理清系统的外部依赖关系,如果存在多个系统共享一个数据库,就会导致耦合问题,影响可用性和扩展性,可能出现如下问题。

    • 当CRM中的数据结构发生变化的时候,OA也要跟着变化,导致开发的过程互相依赖。

    • 有可能在CRM进行的限流是没用的,因为OA没有通过CRM提供的接口进行调用。

    • 假设随着业务的发展,需要在CRM的数据库上做缓存,可能存在多个地方要考虑缓存的问题。

    图2-3 直接访问其他服务的数据库

    总之,接口应该作为唯一对外提供的访问方式,这代表的是控制力。解决方法就是通过接口调用,逐步去除数据库的直接访问。

    1.5 微服务划分模式

    虽然服务是逐步被拆分出来的,随着业务的演进,在某一时刻,可能需要我们重新审视服务划分的是否合理。本节向大家推荐两种服务划分的方法。首先介绍如何选择服务划分的方法。

    1.5.1 基于业务复杂度选择服务划分方法

    根据业务复杂度划分服务,如图2-4所示。当业务复杂度足够高的时候,应该基于领域驱动划分服务,而领域驱动本身足够复杂,很多概念比较抽象,应用范围并不是特别广泛,所以当业务复杂度较低时,可以选择基于数据驱动模式划分服务,数据驱动模式更容易理解和上手,也就是说,除非业务复杂度非常高,否则应该优先以数据驱动模式划分服务。这里的业务复杂度专指业务逻辑,而非数据量、并发量等相关复杂度。

    图2-4 根据业务复杂度划分服务

    在做出选择的时候,还有一个参考指标是,团队以前是否已经基于领域驱动开发业务,也就是说如果产品已经基于领域驱动开发了一段时间,具备了领域驱动开发的能力,那么当然推荐继续选择领域驱动划分服务。如果是一个全新的产品,则可以灵活选择。

    选择服务划分的方法要重点考虑的条件如下。

    • 业务复杂度。

    • 团队对领域驱动的熟悉程度。

    1.5.2 基于数据驱动划分服务

    数据驱动是一个自下而上的架构设计方法,数据驱动强调的是数据结构,也就是通过分析需求,确定整体数据结构,根据表之间的关系划分服务。

    通常基于数据驱动划分服务的步骤如下。

    第一步,需求分析。通过领域专家(或者产品经理)确定目标,然后总结user story,确定核心的业务流程。通过工具呈现比较粗糙的界面,内部讨论。不断迭代此环节,直到满意为止。

    第二步,抽象数据结构。根据需求总结use case,协助分析需求,从中抽象数据结构。

    第三步,划分服务。分析数据结构,识别服务,服务应该满足高内聚、低耦合、单一职责等特征。

    第四步,确定服务调用关系。先分析出主要流程,根据请求需要调用的服务确定服务调用关系。如果存在问题,需要从第一步重新开始。

    第五步,业务流程验证。重新回到user story,以服务为粒度实现时序图,注意此阶段重点是要验证服务划分是否合适,要关注如下问题。

    • 一次更新操作如果要跨越更多服务,那么一致性的要求是什么。

    • 跨服务查询时,是否要做关联查询,一个服务内是否能解决问题。

    • 性能是否能满足要求。

    • 成本是否满足要求。

    第六步,持续优化。

    1.5.3 基于领域驱动划分服务

    领域驱动是一个自上而下的架构设计方法,通过和领域专家建立统一的语言,不断交流,确定关键业务场景,逐步确定边界上下文。领域驱动更强调业务实现效果,认为自下而上的设计可能会导致技术人员不能更好地理解业务方向,偏离业务目标。

    通常基于领域驱动划分服务的步骤如下。

    第一步,通过模型和领域专家建立统一语言。建立统一语言是为了更深入的理解需求,通用语言尽量以业务语言为主,而非技术语言。通用语言和代码一样,需要不断的重构。

    第二步,业务分析。确定核心的业务流程,然后逐步扩展到全部。最好通过工具呈现比较粗糙的界面,内部讨论。

    第三步,寻找聚合。显式地定义了领域模型的边界。为大家介绍一下最近比较热门的事件风暴,事件风暴是一种基于领域驱动分析业务,划分服务的方法。

    事件风暴就是把所有的关键参与者都召集到一个很宽敞的屋子里来开会,并且使用便利贴来描述系统中发生的事情,如图2-5所示。

    • 用桔黄色的便利贴代表领域事件,在上面用一句话描述曾经发生过什么事情。

    • 用蓝色的便利贴代表命令。命令的发起者可能是人,是注入系统中的外部事件,或是定时器等。

    • 用黄色的便利贴代表聚合,聚合是一组相关领域对象的集合,高内聚,低耦合,聚合内保证数据一致性。

    图2-5 事件风暴

    第四步,确定服务调用关系。先分析出主要流程,根据一次请求需要调用的服务确定服务调用关系。如果存在水平划分,则需要根据服务依赖原则确定关系。如果存在问题,则需要从第一步重新开始。

    第五步,业务流程验证。以服务为粒度实现时序图,注意此阶段重点是要验证服务划分是否合适,重点要关注的问题如下。

    • 一次更新操作如果要跨越更多服务,那么一致性的要求是什么。

    • 跨服务查询时,是否要做关联查询,一个服务内是否能解决问题。

    • 性能是否能满足要求。

    • 成本是否满足要求。

    第六步,持续优化。

    1.5.4 从已有单体架构逐步划分服务

    在大多数场景下,并非从开始阶段就采用微服务架构,而是随着业务不断发展,从最初的单体架构中逐步拆分服务。下面描述了从一个单体架构逐步拆分的步骤。

    第一步,所有微服务成功的故事都是从一个单体架构太大,需要被拆散开始的,如图2-6所示。我们应该以单体架构开始,当系统规模足够大、团队人数足够多时,再逐步拆分服务,通常前后端分离是拆分的第一步。

    第二步,提取公共基础服务,如单点登录,拆分可以遵循逻辑分离和物理分离两种方法。另外随着系统压力的增加,可能会用到消息中间件、分布式缓存等服务。

    图2-6 从已有架构逐步拆分服务(一)

    第三步,不断地从老系统抽象服务,垂直划分优先,如图2-7所示。

    图2-7 从已有架构逐步拆分服务(二)

    第四步,当业务越来越复杂的时候,API Gateway做了太多的事情,会成为一个瓶颈点,服务之间的依赖关系也会变得越来越复杂,此时,需要适当地进行水平切分,如图2-8所示。

    图2-8 从已有架构逐步拆分服务(三)

    1.5.5 微服务拆分策略

    当不断从单体架构中抽象服务的时候,哪些服务优先被拆分,哪些服务不需要被拆分?以下几个策略可以帮助拆分。

    • 比较独立的新业务优先采用微服务架构。从成本角度考虑,新业务采用新的架构是最合理的,对老业务的影响最小。

    • 优先抽象通用服务。因为通常通用服务的边界比较明显,耦合度低,比较容易分离。

    • 优先抽象比较容易识别的、边界比较明显的服务。如果原有包结构比较清晰,可以基于原有包结构中有明显边界的、比较完整的业务进行划分,这是从成本角度考虑。如果已经基于单体架构开发了一段时间,对业务的理解程度已经非常高了,那么这时往往开发及架构人员能够比较容易地提炼出一些边界比较明显的服务。

    • 优先抽象核心服务。因为微服务的开发及运维成本比较高,并不是所有的地方都要划分的粒度比较小,往往一些比较边缘的运营、管理的系统就不会拆分,另外,随着时间的推移,有一些业务可能会发生改变,因此,应该先抽象出核心服务。

    • 优先抽象具有独立属性的服务。根据功能的变更频率,资源占用,技术栈等属性划分服务。

    • 采用绞杀者模式,在遗留系统外围,随着时间的推移,新的服务逐渐“绞杀”老的系统。

    这种情况下,复杂度往往体现在如何灰度发布、迁移数据,以及如何保障服务不中断,后面的章节会详细描述。

    本书节选自《持续演进的Cloud Native 云原生架构下微服务最佳实践》


    往期推荐欧创新:深度解析DDD中台和微服务设计领域驱动专家张逸文字脱口秀:简单工厂不简单DDD专家张逸:《解构领域驱动设计》前言Hacker News热文:请停止学习框架,学习领域驱动设计(DDD)(获500个点赞)京东平台研发朱志国:领域驱动设计(DDD)理论启示DDD专家张逸:构建领域驱动设计知识体系领域驱动设计(DDD)在美团点评业务系统的实践当DDD遇上微服务DDD战略篇:架构设计的响应力可视化与领域驱动设计领域驱动设计(DDD)前夜:面向对象思想领域驱动设计(DDD):领域和子域DDD专家张逸:复杂与架构演进的关系滕云:DDD实现之路百度十亿级流量的搜索前端,是怎么做架构升级的?Francisco: 构建前瞻性应用架构的优秀实践这 3 种 DDD 分层架构的模式,你掌握了么?
       END     
    #技术人必备#
    
    
    
    点个在看,让更多人看见
    
    展开全文
  • 目录 一、API 网关的用处二、API网关在企业架构中的地位三、企业中如何应用API网关四、API网关有哪些竞争方案五、API网关解决方案六、企业怎么选择API网关 一、API网关的用处 API网关我的分析中会用到以下三种...

    目录

    一、API 网关的用处  二、API网关在企业架构中的地位  三、企业中如何应用API网关  四、API网关有哪些竞争方案  五、API网关解决方案  六、企业怎么选择API网关

    一、API网关的用处

    API网关我的分析中会用到以下三种场景。

    1、Open API

    企业需要将自身数据、能力等作为开发平台向外开放,通常会以rest的方式向外提供。最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。

    Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等,必然会有一个统一的入口进行管理,这正是API网关可以发挥作用的时候。

    2、微服务网关

    微服务的概念最早在2012年提出,在Martin Fowler的大力推广下,微服务在2014年后得到了大力发展。

    在微服务架构中,有一个组件可以说是必不可少的,那就是微服务网关,微服务网关处理了负载均衡,缓存,路由,访问控制,服务代理,监控,日志等。

    API 网关在微服务架构中正是以微服务网关的身份存在。

    3、API服务管理平台

    上述的微服务架构对企业来说有可能实施上是困难的,企业有很多遗留系统,要全部抽取为微服务改动太大,对企业来说成本太高。

    但是由于不同系统间存在大量的API服务互相调用,因此需要对系统间服务调用进行管理,清晰地看到各系统调用关系,对系统间调用进行监控等。

    API网关可以解决这些问题,我们可以认为如果没有大规模的实施微服务架构,那么对企业来说微服务网关就是企业的API服务管理平台。

    二、API网关在企业架构中的地位

    一个企业随着信息系统复杂度的提高,必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等。

    在架构上应该将这三种应用区别开,三种应用的安排级别、访问方式也不一样。

    因此在我的设计中将这三种应用分别用不同的网关进行API管理,分别是:API网关(OpenAPI合伙伙伴应用)、API网关(内部应用)、API网关(内部公网应用)。

    如下图所示:

    你连微服务的网关都说不清楚,还天天鼓捣着要把项目拆分微服务?

     

    三、企业中如何应用API网关

    1、对于OpenAPI使用的API网关来说,一般合作伙伴要以应用的形式接入到OpenAPI平台,合作伙伴需要到 OpenAPI平台申请应用。

    因此在OpenAPI网关之外,需要有一个面向合作伙伴的使用的平台用于合作伙伴,这就要求OpenAPI网关需要提供API给这个用户平台进行访问。

    如下架构:

    你连微服务的网关都说不清楚,还天天鼓捣着要把项目拆分微服务?

     

    当然如果是在简单的场景下,可能并不需要提供一个面向合作伙伴的门户,只需要由公司的运营人员直接添加合作伙伴应用id/密钥等,这种情况下也就不需要合作伙伴门户子系统。

    2、对于内网的API网关,在起到的作用上来说可以认为是微服务网关,也可以认为是内网的API服务治理平台。

    当企业将所有的应用使用微服务的架构管理起来,那么API网关就起到了微服务网关的作用。

    而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理,那么API网关起到的就是API服务治理的作用。

    架构参考如下:

    你连微服务的网关都说不清楚,还天天鼓捣着要把项目拆分微服务?

     

    3、对于公司内部公网应用(如APP、公司的网站),如果管理上比较细致,在架构上可能由独立的API网关来处理这部分内部公网应用

    如果想比较简单的处理,也可以是使用面向合作伙伴的API网关。

    如果使用独立的API网关,有以下的好处:

    • 面向合作伙伴和面向公司主体业务的优先级不一样,不同的API网关可以做到业务影响的隔离。
    • 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
    • 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

    基于以上的分析,如果公司有能力,那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

    四、API网关有哪些竞争方案

    1、对于Open API平台的API网关,我分析只能选择API网关作为解决方案.

    业界没有发现比较好的可以用来作为Open API平台的入口的其他方案。

    2、对于作为微服务网关的API网关,业界的选择可以选择的解决方案比较多,也取决于微服务器的实现方案,有一些微服务架构的实现方案是不需要微服务网关的。

    (1)Service Mesh

    这是新兴的基于无API网关的架构,通过在客户端上的代理完成屏蔽网络层的访问,这样达到对应用层最小的改动

    当前Service Mesh的产品还正在开发中,并没有非常成熟可直接应用的产品。发展最迅速的产品是Istio。建议大家密切关注相关产品的研发、业务使用进展。

    你连微服务的网关都说不清楚,还天天鼓捣着要把项目拆分微服务?

     

    (2)基于duboo架构

    在这个架构中通常是不需要网关的,是由客户端直接访问服务提供方,由注册中心向客户端返回服务方的地址。

    你连微服务的网关都说不清楚,还天天鼓捣着要把项目拆分微服务?

     

    五、API网关解决方案

    公有云解决方案:

    • Amazon API Gateway:
    • https://aws.amazon.com/cn/api-gateway/
    •  
    • 阿里云API网关:
    • https://www.aliyun.com/product/apigateway/
    •  
    • 腾讯云API网关:
    • https://cloud.tencent.com/product/apigateway

    自开发解决方案:

    • 基于Nginx+Lua+ OpenResty的方案,可以看到Kong,orange都是基于这个方案
    • 基于Netty、非阻塞IO模型。通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案,是一种成熟的方案。
    • 基于Node.js的方案。这种方案是应用了Node.js天生的非阻塞的特性。
    • 基于java Servlet的方案。zuul基于的就是这种方案,这种方案的效率不高,这也是zuul总是被诟病的原因。

    六、企业怎么选择API网关

    如果要选择一款已有的API网关,需要从以下几个方面去考虑。

    1、性能与可用性

    如果一旦采用了API网关,那么API网关就会作为企业应用核心,因此性能和可用性是必须要求的。

    从性能上来说,需要让网关增加的时间消耗越短越好,个人觉得需要10ms以下。

    系统需要采用非阻塞的IO,如epoll,NIO等,网关和各种依赖的交互也需要是非阻塞的,这样才能保证整体系统的高可用性,如:Node.js的响应式编程和基于java体现的RxJava和Future。

    网关必须支持集群部署,任务一台服务器的crash都应该不影响整体系统的可用性。

    多套网关应该支持同一管理平台和同一监控中心。如:一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

    2、可扩展性、可维护性

    一款产品总有不能满足生产需求的地方,因此需求思考产品在如何进行二次开发和维护,是否方便公司团队接手维护产品。

    3、需求匹配度

    需要评估各API网关在需求上是否能满足。

    比如:如果是OpenAPI平台需要使用API网关,那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。

    如果是微服务网关,那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。

    4、是否开源?公司是否有自开发的能力?

    现有的开源产品如kong,zuul,orange都有基础的API网关的核心功能,这些开源产品大多离很好的使用有一定的距离

    比如:没有提供管理功能的UI界面、监控功能弱小,不支持OpenAPI平台,没有公司运营与运维的功能等。

    当然开源产品能获取源代码,如果公司有比较强的研发能力,能hold住这些开源产品,经过二次开发kong、zuul应该还是适应一些公司,不过需求注意以下一些点:

    • kong是基于ngnix+lua的,从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。
    • zuul因为架构的原因在高并发的情况下性能不高,同时需要去基于研究整合开源的适配zuul的监控和管理系统。
    • orange由于没有被大量使用,同时是国内个人在开源,在可持续性和社区资源上不够丰富,出了问题后可能不容易找到人问。

    另外kong提供企业版本的API网关,当然也是基于ngnix+lua的,企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。

    5、公有云还是私有云

    现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关,当然这些网关的基础功能肯定是没有问题,但是二次开发,扩展功能、监控功能可能就不能满足部分用户的定制需求了。

    另外很多企业因为自身信息安全的原因,不能使用外网公有网的API网关服务,这样就只有选择私有云的方案了。

    在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用,无法做到定制的合作伙伴门户,这也不适合于部分企业的需求。

    如果作为微服务网关,大多数情况下是希望网关服务器和服务提供方服务器是要在内网的,在这里情况下也只有私有云的API网关才能满足需求。

    综合上面的分析,基础公有云的API网关只有满足一部分简单客户的需求,对于很多企业来说私有云的API网关才是正确的选择。

    展开全文
  • 微服务拆分

    2021-01-03 23:30:14
    微服务拆分 对在线教室业务来说,包括用户服务、在线教室服务、行为牌服务、回放服务、课件服务、信令服务、监课服务、在线教室反馈等等 电子商务:用户服务User、商品服务Info、交易平台Trade、搜索服务Search、...

     

    微服务拆分

    对在线教室业务来说,包括用户服务、在线教室服务、行为牌服务、回放服务、课件服务、信令服务、监课服务、在线教室反馈等等

    电子商务:用户服务User、商品服务Info、交易平台Trade、搜索服务Search、推荐引擎等

    1、垂直拆分

    拆不拆分主要看业务是物理关系还是逻辑关系 用户与商品是业务关系、商品与交易是业务关系等
    用户与在线教室是业务关系、商品与交易是业务关系等

    物理关系就是在同一个数据库,一般一个微服务都是独立部署、单进程、独立数据库

    拆分粒度问题:假如用户服务有注册、登陆、查询等功能,
    注册是写服务、登陆和查询都是读服务。
    读写比例是1:10 ,有的是1:1万 1:10万 比如腾讯登陆、读写比能达到1:10万以上的是博客系统,比如简书的文章阅读人数几十万。
    读写比超过1:10,或者QPS达到1000以上 可以考虑拆分注册服务、登陆查询服务
    登陆查询会影响到写服务注册。
    拆分到API层 应该是最小粒度的拆分了。

    商品的发布和查询服务,当商品的访问量比较大的时候,也是要考虑去拆分。

    光垂直拆分是不够的,比如搜索访问DB或者Cache,当访问量大的时候就需要水平拆分

    2、水平拆分

     

    微服务的拆分规范和原则

    拆分方案

    • 压力模型拆分
    • 业务模型拆分
      --主链路拆分
      --领域模型拆分
      --用户群体拆分
      --前后台业务拆分

    高频高并发场景

    比如商品详情页,高频场景 时时刻刻都会发生,商品详情页 并发量最大的业务
    一笔成功达成的订单交易背后,可能会调用几十次商品详情页接口 货比三家

    低频突发流量场景

    比如前面提到的秒杀 突发流量 商品发布 新零售业务

    低频低流量场景

    这一类多为后台运营团队的服务接口,比如商品图文编辑,添加新的优惠计算规则,上架新商品。它发生的频率比较低,而且不会造成很高的并发量

    通常我们建议将高频高并发的场景隔离出来,单独作为一个微服务模块,典型的就是商品详情页的后台服务。对低频突发流量的场景,如果条件允许也可以剥离出来独立组成模块,如果必须和其他业务包在一个微服务下,那一定要做好流控措施(最典型的就是削峰策略),而且还要考虑到异常情况下的补偿机制,对于低频流量场景,我们根据业务模型切分就好了

    业务模型拆分 业务模型拆分的维度有很多,我们在实际项目中应该综合各个不同维度做考量。我这里主要从主链路、领域模型和用户群体三个维度来讲一下

    2.1 主链路拆分

    在电商领域“主链路”是一个很重要的业务链条,它是指用户完成下单场景所必须经过的场景。按照我们平时买买买的剁手经验,可以识别出很多核心主链路,比如商品搜索->商品详情页->购物车模块->订单结算->支付业务

    电商领域背后还有很多隐藏的核心主链路,比如下单之前的营销优惠结算,它会影响订单的最终价格;再比如用户地址模块,它会影响下单前的配送地址选择。如果这两个模块出了问题,大部分用户恐怕都要放弃下单了。尤其是双十一我们添加了一篮子购物车,结果结算的时候发现所有优惠组合都失效了,或者是无法选择配送地址,那要果断放弃,甚至卸载了。

    核心链路拆分的目的:

    1、异常容错

    为主链路建立层次化的降级策略(多级降级),以及合理的熔断策略

    2、调配资源

    主链路通常将都是高频场景,自然需要更多的计算资源,最主要的体现就是集群里分配的虚拟机数量多。将主链路服务单独隔离出来,这样有利于根据需要指定资源计划(比如双十一阶段为每个主链路服务拟定不同的扩容计划)

    3、服务隔离

    主链路是主打输出的C位,把主链路与其他打辅助的业务服务隔离开来,避免边缘服务的异常情况影响到主链路

    2.2 领域模型拆分

    领域驱动设计DDD(Domian-Driven Design 领域驱动设计)

    领域的合并:淘宝系的营销优惠服务,曾经天猫和淘宝各有一套营销服务,如果不考虑底层技术,从业务层面来说,他们做的事情是一样的,都属于营销优惠计算的领域范围,因此后面两条技术线整合成一套UMP营销优惠服务;

    领域的拆分:微服务的规划需要确保各个领域之间有清晰的界限,比如商品服务、订单服务,尽管他们之间有交集,都围绕商品主数据,但是毕竟是服务于不同领域:商品域和订单域,所以我们将它们拆分成独立的服务

    2.3 用户群体拆分

    根据用户群体拆分,需要了解自己系统业务有哪些用户,比如说电商领域,我们有2C的小卖家,也有2B的大客户,在集团内部有运营、采购、还有客服小二等等。对每个不同的用户群体来说,即便是相同的业务领域,也有该群体其独有的业务场景

    用户群体相当于一个二级域,建议先根据主链路和领域模型做一级域的拆分,再结合具体的业务分析,看是否在用户领域方向上做更细粒度的拆分

    2.4 前后台业务分离

    网约车业务不仅仅有一个乘客app,也有一个司机端app

    电商领域:手淘app买买买(前台业务场景),商家通过后台的业务系统管理商品信息(后台业务场景)。

    在实际项目中通常也会将前台业务和后台业务做一个隔离,这也符合高频业务(前台)和低频业务(后台)的隔离策略

    展开全文
  • springboot-plus 一个基于SpringBoot 2 的管理后台系统,有数十个基于此的...要明白单体系统,系统拆分微服务三个不同构建开发平台方式,plus支持单体和系统拆分,一般而言,后台管理系统适合单体和系统拆分微服务

    springboot-plus

    一个基于SpringBoot 2 的管理后台系统,有数十个基于此的商业应用,包含了用户管理,组织机构管理,角色管理,功能点管理,菜单管理,权限分配,数据权限分配,代码生成等功能 相比其他开源的后台开发平台脚手架,SpringBoot-Plus 使用简单,可以轻易完成中型,大型系统开发。同时技术栈较为简单

    如何判断一个开源开发平台适合自己

    • 要明白单体系统,系统拆分,微服务三个不同构建开发平台方式,plus支持单体和系统拆分,一般而言,后台管理系统适合单体和系统拆分。微服务并不适合系统管理,以我知道的互联网大厂,央企后台管理系统,还是以前俩个为多
    • 你需要的是技术框架还是开发平台,技术框架就是技术堆砌,开发平台必须具备一定复杂基础业务功能
    • 看权限模型,支持功能权限和数据权限。plus具备强大的功能权限和数据权限,且可以扩展n种数据权限
    • 看用户是否能属于多个部门,用户兼职情况很常见
    • 看数据字典是否支持级联,数据字典级联太常见了,平台需要提供数据和前端的支持。puls系统支持
    • 看代码生成是否支持预览,为什么要预览,因为生成会覆盖,预览可以修改已经生成的代码

    Plus系统是一个使用简单,功能较为复杂的开源系统,已经数十家商业公司采用

    系统基于Spring Boot2.1技术,前端采用了Layui2.4。数据库以MySQL/Oracle/Postgres/SQLServer为实例,理论上是跨数据库平台.

    基本技术栈来源于我为电子工业出版社编写的的<<Spring Boot 2 精髓 >> (这本书每一章也有各种例子,但Springboot-plus 更偏向于应用而不是教学) 该书的第二版电子版可以可以在看云广场购买, 包含基础篇,分布式篇和微服务篇,第二版也包含一章说明Plus系统

    我的新书,程序员性能优化,程序装B宝典《Java系统性能优化》,可以在京东上购买了

    当前版本:1.3.0

    技术交流群:252010126

    免费视频介绍:https://pan.baidu.com/s/1dFPoaT7

    开源地址:https://gitee.com/xiandafu/springboot-plus

    视频介绍:https://pan.baidu.com/s/1dFPoaT7

    doc/readme/user.png doc/readme/user.png doc/readme/user.png doc/readme/user.png doc/readme/user.png doc/readme/user.png doc/readme/user.png doc/readme/user.png

    1 使用说明

    1.1 安装说明

    建议在彻底熟悉plus系统之前,先暂时不要修改其他配置选项,免得系统无法访问

    本系统基于Spring Boot 2 ,因此请务必使用JDK8,且打开编译选项parameters(点击了解parameters), 并重新编译工程,如果你没有使用Java8的 parameters 特性,系统不能正常使用

    从Git上获取代码后,通过IDE导入此Maven工程,包含俩个子工程

    • admin-core ,核心包,包含了缓存,数据权限,公用的JS和HTML页面。
    • admin-console, 系统管理功能,包含了用户,组织机构,角色,权限,数据权限,代码生成等管理功能

    com.ibeetl.admin.CosonleApplication 是系统启动类,在admin-console包下,在运行这个之前,还需要初始化数据库,位于doc/starter-mysql.sql,目前只提供mysql, oracle, postgresql脚本。理论上支持所有数据库

    还需要修改SpringBoot配置文件application.properties,修改你的数据库地址和访问用户

    spring.datasource.baseDataSource.url=jdbc:mysql://127.0.0.1:3306/starter?useUnicode=true&characterEncoding=UTF-8&serverTimezone=GMT%2B8&useSSL=false&useInformationSchema=true
    spring.datasource.baseDataSource.username=root
    spring.datasource.baseDataSource.password=123456
    spring.datasource.baseDataSource.driver-class-name=com.mysql.cj.jdbc.Driver
    

    运行CosonleApplication,然后访问http://127.0.0.1:8080/ 输入admin/123456 则可以直接登录进入管理系统

    如果成功启动后运行报错:变量userId未定义,位于第6行,那是因为你没有启用parameters,启用后,需要clean&build整个工程

    微信扫描付费查看安装和子系统生成视频(约25分钟)

    doc/readme/user.png

    1.2 创建子系统

    SpringBoot-plus 是一个适合大系统拆分成小系统的架构,或者是一个微服务系统,因此,如果你需要创建自己的业务系统,比如,一个CMS子系统,建议你不要在SpringBoot-Plus 添加代码,应该是新建立一个maven工程,依赖admin-core,或者依赖admin-console(如果你有后台管理需求,通常都有,但不是必须的)

    创建子系统,可以进入代码生成>子系统生成, 输入maven项目路径,还有包名,就可以直接生成一个可运行的基于SpringBoot-Plus 的子系统,所有代码可以在个项目里些完成,直接运行MainApplication,

    @SpringBootApplication
    @EnableCaching
    @ComponentScan(basePackages= {"com.corp.xxx","com.ibeetl.admin"})
    public class MainApplication  extends SpringBootServletInitializer implements WebApplicationInitializer {
    	
        public static void main(String[] args) {
        	
        	SpringApplication.run(MainApplication.class, args);
        }
    
    
    }	

    子系统包含了admin-core和admin-console, 因此你可以直接在子系统里使用core和console提供的所有功能,通过子系统的console功能的代码生成来完成进一步开发

    子系统可以单独运行和维护,也可以集成到nginx后构成一个庞大的企业应用系统

    1.2.1 配置子系统

    子系统不需要做任何配置即可在IDE里直接运行,如果你想打包jar方式运行,则需要添加

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

    如果你想打包成war放到tomcat下运行,需要修改maven打包为war

    <packaging>war</packaging>

    1.2.2 菜单系统

    系统默认提供三种类型菜单

    • 系统级菜单,出现在页面顶部,表示一个子系统
    • 导航菜单,出现在页面左边,点击导航将打开其下所有菜单
    • 菜单,点开菜单将定位到页面,菜单必须关联到一个功能点。

    建议新建立一个子系统来放置新功能

    SpringPlus-Boot 并非以菜单或者按钮来组织整个系统,而是以功能点来组织整个系统提供的功能。如果要使得菜单生效,你必须要先常见一个功能点并且功能点有一个访问地址,然后将此菜单关联到这个功能点

    SpringBoot-Plus 先建立功能点是个好习惯,功能点被组织成一颗树,代表了系统应该提供功能的功能,我们看代码就会看到,功能点跟菜单,跟权限,和数据权限都有密切关系

    1.2.2 添加代码

    可以参考1.3业务代码生成生成初始化的代码,业务代码生成了14个文件,包含前后端所有代码,可以通过生成来了解代码习作规范

    1.3 业务代码生成

    在介绍如何利用Plus开发系统之前,先介绍代码生成功能,此功能可以生成前后端代码总计14个文件,你可以通过预览功能了解如何开发这个系统

    doc/readme/user.png

    代码生成针对表进行代码生成,包括JS,JAVA,SQL和HTML,可以通过预览功能直接预览。在生成代码到本地前,有些参数需要修改,否则,代码生成后显示的都是英文

    • 显示字段 : 当此实体显示在任何地方的时候,能代表此实体的名称,比如用户名,组织机构名
    • 变量名:可以自己设定一个较短的名字,此变量名会用于前后端的变量
    • urlBase:你规划的子系统,最后访问路径是urlBase+变量名字
    • system: 存放sql目录的的名称

    其他修改的地方有

    是否包含导入导出,如果选择,则会生成导入导出的代码,导入导出模板则需要参考已有功能(比如数据字典)来完成

    是否包含附件管理,如果选择,则业务对象可以关联一组附件,比如客户关联一组附件,或者申请信息关联一组附件。

    字段信息的显示名字,这个用于前端列表,表单的显示,应当输入中文名字

    作为搜索,可以勾选几个搜索条件,系统自动生成一个搜索配置类

    如果字段关联数据字典,那么设置一个数据字典,这样,生成的界面将会变成一个下拉列表

    1.3.1 前端代码

    前端代码采用了layui的JS框架,使用了按需加载的方式,文档参考 http://www.layui.com/doc/base/infrastructure.html.

    • index.js: 系统入口JS,包含了查询和表格
    • add.js : 新增操作的所有JS
    • edit.js: 编辑操作的所有JS
    • del.js: 删除操作的所有JS

    基础JS

    • Common.js: 封装了通常JS功能,如jquery的post方法,layui的窗口方法
    • Lib.js 封装了业务相关方法,如submitForm,loadOrgPanel等方法

    1.3.2 HTML代码

    页面采用layui,文档参考 http://www.layui.com/demo/

    模板语言了使用Beetl,文档参考ibeetl.com

    • index.html: 功能首页
    • add.html: 新增首页
    • edit.html: 编辑操作首页

    采用layui的好处是自带了页面和组件还有JS的管理,能完成大多数业务需求

    基础UI组件:

    • orgInput.tag.html 组织机构输入框
    • simpleDictSelect.tag.html 字典下拉列表
    • simpleDataSelect.tag 包含key-value的下拉列表
    • searchForm.tag.html 通用搜索表单
    • submitButtons.tag.html 提交按钮
    • accessButton.tag.html 普通按钮(含权限)
    • attachment.tag.html 附件管理组件
    • ....

    2 单体系统,系统拆分和微服务

    plus是一个适合单体系统,系统拆分的java快速开发平台,也可以经过改造成微服务平台(以前做一个版本,但觉得plus应该聚焦系统核心,而不是简单堆砌功能,所以放弃了)

    以下是单体系统,小系统,和微服务的区别

    单体系统是一种常见系统设计方式,也是这十几年年来最主要的设计方式。单体系统的所有功能都在一个工程里,打成一个war包,部署。这样有如下明显好处

    • 单体系统开发方式简单,我们从刚开始学习编程,就是完成的单体系统,开发人员只要集中精力开发当前工程
    • 容易修改,如果需要修改任何功能,都非常方便,只需要修改一个工程范围的代码
    • 测试简单,单体系统测试不需要考虑别的系统,避免本书下册要提到的各种REST,MQ调用
    • 部署也很容易:不需要考虑跟别的系统关系,直接打war包部署到Web服务器即可
    • 性能容易扩展,可以通过Nginx,把一个应用部署到多个服务器上。

    随着业务发展,重构,单体系统越来越多,在开发一个庞大的单体系统的时候,就会有如下弊病

    • 单体系统庞大,越来越难理解单体系统,微小的改动牵涉面广泛导致开发小组小心谨慎,开发速度会越来越慢。另外,启动一个庞大的单体系统,可能需要3分钟,或者更多时间
    • 多个功能在同一个单体系统上开发,导致测试越来越慢,比如,测试必须排期,串行测试
    • 单体系统如果想对技术进行更新换代,那代价非常大,如果是个小系统构成,则可以选取一个小系统先做尝试。单体大系统是几乎不可能做技术升级的
    • 单体系统的所有功能运行在同一个JVM里,功能会互相影响,比如一个统计上传word文档的页码的功能由于非常消耗CPU,因此,会因为调用统计功能,导致整个系统短暂都不可用,出现假死的现象

    因此,越来越多的架构师在设计系统的时候,会考虑系统拆分成多个单体小系统甚至是微服务。对于传统企业应用,拆成小系统更合适,对互联网系统,使用微服务个更合适,这是因为

    • 传统IT系统本质上还是会用一个数据库,而微服务提倡的是一个服务一个数据库
    • 传统IT系统很少需要调用其他模块服务。传统IT系统通过工作流来串联其他子系统。而电商类的微服务则是通过RPC等方式进行交互,是一个轻量级协议。传统IT系统也可以通过SOA,JMS跟其他系统(非子系统)交互,采用重量级协议
    • 微服务对系统的基础设施要求很高,比如微服务治理,弹性库等等,只要电商系统才有人力物力去做这种事情,而传统IT系统,及时财大气粗,也暂时不具备微服务那样的IT基础设置

    因此,对于大多数传统IT应用来说,单体拆分小系统在技术上没有风险,是一个可以立即实施的架构。如下是一个单体系统拆分后的物理架构

    design

    对于用户来说,访问不同的菜单功能,讲定位到不同得子系统,提供服务。

    plus支持多数据库

    展开全文
  • 微服务不是万能的,也不要为了微服务微服务。能够支持业务在各个阶段的成长是第一位的,就好比泡泡平台从最开始定位的的社交(聊天、发帖),到目前的明星、兴趣社区和运营推广,再到未来的不同业务的基础平台,每...
  • 公司希望通过微服务拆分实现代码复用,可能会有多个平台,可实现多平台使用同一个微服务。 <p>1、微服务是可独立运行的一个整体,如果使用rpc调用其它系统是不是就算耦合了?比如我有一个...
  • 微服务拆分(1) 继上文提出“微服务边界如何划分”的问题后,后台有不少朋友留言,我也拉群组跟大家进行了相关讨论,总结如下: 使用微服务后,随着需求不断复杂化,微服务间边界越发不清晰,层次越发复杂,耦合...
  • 微服务与DDD领域驱动设计模型 什么是DDD领域驱动设计 最先介绍领域驱动设计(domain-driven design)的是在程序员Eric Evans2004年出版的《领域驱动设计:复杂软件核心复杂应对之道》书籍中,领域驱动设计是领域...
  • 微服务拆分规范和原则

    千次阅读 2020-05-28 12:05:02
    目录拆迁方案1、压力模型拆分2、业务模型拆分2.1 主链路拆分2.2 领域模型拆分2.3 用户群体拆分2.4 前后台业务分离 前面我们了解了什么是微服务和为什么需要做微服务架构(What & Why),这一章我们就来探讨如何...
  • 业务模型拆分:前后台业务拆分、主链路查费、领域模型拆分、用户群体拆分 压力模型拆分:对于高并发量的业务,尽可能独立成微服务拆分 1.压力模型拆分 压力模型拆分,就是说根据用户对业务的访问量的高频进行拆分,...
  • 公司之前的项目是一个基于springCloud 的简单微服务架构,很多业务逻辑都是堆积在同一个服务中,企业端是一个服务,用户端也是一个服务,管理后台是一个服务,部门老大打算安排我把这个项目进行和他的服务合并改造成...
  • AKF拆分原则业界对于可扩展系统架构设计有一个朴素的理念:通过加机器就可以解决容量和可用性问题。这一理念在云计算概念疯狂流行的今天,得到了广泛的认可,对于一个规模迅速增长的系统而言,容量...
  • 作者:克里斯·理查森译者:喻勇来源:《微服务架构设计模式》经出版社授权发布导读:微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,或者在做微服务的路上,拆分服务是个很热的话...
  • 微服务

    2018-08-12 10:35:16
    一、微服务介绍 1. 什么是微服务  在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微"、什么是"服务", 微 狭义来讲就是体积小、著名的"2 ...
  • 这里我大概分为这么几个流派: 保守派: 大多场景是本身已经存在了一个单体巨无霸系统,考虑的是...比如原项目是一个商城系统,包括商城前台,订单管理,商品管理等后台功能。 拆分后: 商城前台、个人中心、商城...
  • 微服务面面观 微服务基本 单体应用 单体应用的优点? --易于开发 --易于测试 --易于部署 存在的问题: --代码耦合,开发维护困难,提交代码频繁出现大量冲突 --主要业务和次要业务耦合,无法针对不同模块...
  • Cloud微服务平台是一款基于SpringCloud框架研发的分布式微服务框架,主要使用技术栈包括: SpringCloud、Vue、ElementUI、MybatisPlus,是一款精心打造的权限(RBAC)及内容管理系统,致力于做更简洁的后台管理框架,...
  • 一、 微服务架构的优与劣 微服务架构最近几年发展迅猛,尤其是从2017年以来在业界异常火爆。不论是基于云原生技术的新应用,还是已有的复杂单体应用,都在朝着微服务化的方向进行构建和改造。  微服务架构带来了很...
  • 微服务领域的大多数参考书目都着重于如何拆分单体、领域驱动设计、编排与同步、如何拆分数据库等。但人们往往不会提到后台进程,以及如何在微服务架构环境中实现它们。 关于这一点,我会推荐 Sam Newman 的《构建微...
  • 随着业务规模的不断扩大,我们的后台管理系统逐步变成一个单体巨无霸,用户、商家、运营等等各种功能全部集中在一个系统中,随着而来的问题也越来越多 所有业务部门都可以修改公共部分和核心部分的代码 启动慢,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,252
精华内容 4,100
关键字:

后台拆分微服务