登录社区云,与社区用户共同成长
邀请您加入社区
以内容、博物馆、世界、用户、AI 与 CMS 六个 Spring Boot 服务拆开领域职责,并通过统一契约、持久化与健康回读守住探索主链路。
本文介绍了智能家居App首页的设计与实现,重点分析了其数据架构和交互逻辑。首页作为控制中枢,整合了设备状态、房间导航、快捷控制、能耗统计和智能场景五大功能模块,采用紫色主色调(#6C5CE7)体现科技感。数据层通过Device、Room、Scene和EnergyRecord四个核心接口定义,并实现设备开关、状态统计等基础操作函数。界面采用ArkTS框架开发,利用@State装饰器实现双向数据绑定,
本文介绍了一个旅行天气页面的设计与实现。页面采用"选城市→看天气"的简洁设计,包含城市选择栏、当前天气卡片、四项指标和五天预报。数据结构采用Record<number, Weather>映射表,通过城市ID快速查找天气数据,提高了灵活性和查询效率。城市选择栏采用横向滚动Tab设计,天气主卡片突出显示温度信息作为视觉重心,四项指标间用1px竖线分隔。文章还讨论了数据获取的防御性处理、UI组件的实现细
本文介绍了旅行探索App个人中心页面的设计与实现,重点分析了其与运动健康App的异同。旅行App创新性地引入了UserDataService数据服务层,统一管理用户状态数据(收藏城市、打卡景点、收藏美食),使个人中心从展示页面升级为数据聚合中心。页面采用模块化布局,包含用户卡片、统计区域、收藏城市列表和功能菜单。通过onPageShow生命周期实现数据实时刷新,确保跨页面操作后数据一致性。技术亮点
本文介绍了一个基于HarmonyOS ArkTS技术栈的旅行探索App项目。该App采用首页+多页面结构,包含7个功能页面(如城市详情、美食指南等)。设计上突出橙色渐变Hero Banner和城市卡片网格布局,数据采用嵌套结构(城市对象包含景点和美食数组)。主要特点包括: 视觉设计:主色调采用旅行主题的橙色渐变体系,Banner采用三段渐变增强层次感 页面结构:复用已验证的Stack+Scroll
这篇文章总结了8个HarmonyOS应用页面的统一设计模式和开发经验。主要发现包括:1)所有页面采用Stack+Scroll+BottomNav的骨架布局;2)导航栏右侧按钮按功能定制;3)颜色常量需语义化定义;4)@State数组更新必须创建新引用(slice模式);5)@Builder用于组件封装、列表项和条件渲染;6)路由跳转分带参和不带参两种;7)数据层采用"接口+常量+函数"结构;8)运
本文详细解析了健身App的核心数据层设计文件WorkoutData.ets,重点介绍了三个数据模型(Exercise训练动作、WorkoutPlan训练计划、ActivityRecord活动记录)、三个数据数组(EXERCISES动作库、WORKOUT_PLANS训练计划、WEEKLY_DATA周活动数据)以及两个工具函数。文章特别强调了"ID引用"的数据组织方式,这种设计能实现动作与计划间的解耦
HarmonyOS运动健康——饮食记录页面
本文介绍了运动健康App个人中心页面的设计实现。该页面分为三部分:顶部导航栏(含返回按钮、标题和设置图标)、用户信息卡片(展示头像、昵称和运动标签)、数据统计区(累计运动天数、消耗卡路里等核心指标),以及底部功能菜单(运动记录、饮食记录等6个入口)。 页面采用分层信息架构:从身份识别(我是谁)→行为数据(我做了什么)→功能入口(我能做什么)。视觉设计保持一致性,如红/橙/蓝分别对应运动/卡路里/训
运动健康App的社区页面设计摘要:该页面通过社交功能将个人运动行为转化为群体互动体验。采用简洁的纵向信息流布局,包含顶部导航栏(返回按钮+标题)和帖子卡片流,每张卡片展示用户头像(emoji)、昵称、运动动态、点赞评论等社交元素。数据结构精简(Post接口含5个基础字段),原型阶段使用Scroll+Column渲染静态内容,未来需优化为List组件支持动态交互。设计保持整体App的视觉一致性,包括
本文介绍了训练计划应用的两个页面交互流程:WorkoutPage展示动作列表并选择计划,ExerciseDetail展示单个动作的详细信息。WorkoutPage通过横向滚动的计划卡片和动作列表实现交互,点击动作跳转至详情页并传递动作ID参数。ExerciseDetail根据ID加载数据,展示大图标、标签行、目标肌群和分步骤说明。页面设计注重视觉层级,如难度标签突出显示、步骤编号使用红色圆形等,提
购物商城实现了一套完整的登录系统,包含三个核心模块:AuthService负责登录状态管理(使用内存变量暂存状态),Index.ets通过生命周期钩子实现路由守卫,LoginPage提供完整的交互界面。登录页采用三层视觉设计:渐变背景+动态光晕+功能卡片,其中卡片通过半透明背景和阴影实现类毛玻璃效果,输入框与按钮遵循标准表单交互逻辑。该系统采用最小化设计原则,未来可通过改造AuthService无
本文针对导航系统优化提出了两项核心改进:路由分化和参数驱动。原系统中14个可点击区域有13个跳转至MessagePage,导航功能形同虚设。优化后,菜单项根据实际功能分化为跳转至ProfileEdit、MessageDetail、ProductList和ServiceChat四个目标页面。其中MessageDetail作为通用详情页,通过接收路由参数动态渲染不同内容,既保持了页面统一性又实现了视觉
本文介绍了个人中心页面的交互优化方案,重点解决了原页面菜单项无法跳转的问题。通过重构页面组件化策略,主要进行了三方面优化: 为@Builder Menu组件增加action参数,实现UI与逻辑解耦,通过函数参数延迟执行特性支持点击跳转; 抽取Divider为独立@Builder Div组件,避免样式重复定义; 按用户心智模型重组菜单分组,将功能分为"购物相关"和"账号管理"两类。 优化后代码结构更
本文介绍了电商App购物车页面的设计与实现,主要涵盖以下内容: 核心功能:购物车作为中转站,实现商品选择、数量调整和价格计算三大功能。 数据管理:通过CartService提供完整的购物车操作接口,包括获取列表、删除商品、修改数量、切换选中状态等。 状态刷新机制:采用集中式refresh()方法统一更新购物车列表、全选状态、总价和推荐商品等联动状态。 空状态处理:当购物车为空时展示引导界面和推荐商
文章摘要:本文介绍了一个发现页卡片设计的优化方案。旧版所有卡片统一使用🔧图标,导致用户难以快速区分内容。新版为每个设备类型添加专属emoji图标(如📱、💻、🎧),并简化点赞数为纯数字。重构后的DiscoverCard组件采用对象传参,增大图标尺寸和圆角,调整背景色透明度,并添加心形图标和极淡阴影提升视觉层次。这些改进使内容识别更直观,界面更简洁美观。
协议无感集成:泛型设备管理器统一接入多源设备弹性服务治理:微服务集群动态应对开学/考试等流量高峰原子化操作保障:分布式事务确保设备联动零失误合规隐私保护:数据脱敏与TEE加密满足GDPR/FERPA要求未来可结合盘古大模型实现故障预测前移,当轴承振动数据异常时,系统自动触发维护工单并调整课堂安排,真正构建“感知-决策-执行”闭环的智慧校园神经中枢。代码开源地
/ 实现自定义处理逻辑本文详细介绍了如何在HarmonyNext平台上使用ArkTS构建一个高性能的微服务架构。通过实际案例,我们展示了从架构设计到具体实现的完整过程。该架构具有良好的扩展性和性能,可以满足各种复杂的微服务需求。希望本文能为开发者构建高效、可靠的HarmonyNext应用提供有价值的参考。
金融数字化能力成熟度指引》(JR/T 0271-2023)提出了金融数字化能力成熟度模型、成熟度计算方法,明确了不同维度金融数字化转型能力相应的分档要求,为金融机构提供了一个衡量和提升其金融科技应用和数字化转型水平的重要工具。4个子域为敏捷化创新体系建设(3个能力项)、一体化经营中台建设(3个能力项)、自动化风险防控机制建设(3个能力项)、数智化营销能力建设(3个能力项)。4个子域为服务流程重塑(
截至2025年12月,搭载HarmonyOS 5和HarmonyOS 6的终端设备数突破2700万,鸿蒙生态上架超20000款游戏,鸿蒙游戏玩家超1300万。这不仅是对技术路线的创新,更是对整个产业生态的重构。HarmonyOS 5.0搭载的方舟引擎3.0通过动态代码切片技术对高频路径代码进行按需编译,结合“一次编译,多端部署”的跨平台能力,实现整机性能40%的提升,操作跟手性优化21%。对于开发
这次迁移实践让我们对仓颉有了更立体的认识。它已经具备了成为工程化后端语言的关键能力:首先是可交付性。仓颉能够编译为单一原生二进制文件,这意味着在部署时,我们不再需要再目标机器上安装繁重的运行时环境(如 Node.js 或 JVM),极大地简化了运维流程。其次是可控性。静态类型系统和显式的 I/O 控制,虽然在开发初期增加了编码负担,但迫使我们在编码阶段就必须思考边界条件和潜在错误。从长期维护的角度
早在2023年12月7日支付宝宣布将全面启动鸿蒙原生应用开发。华为表示,支付宝将基于HarmonyOS NEXT版本开发应用,给消费者带来全场景的新体验。头部应用伙伴的加入,大力推动了鸿蒙生态进一步完善。就近期蚂蚁集团开始招聘华为鸿蒙应用研发工程师。。在这可以看出该岗位面向的工种人群没有像一些传统的开发岗位那么局限了。。说实话,这种情况**不管在各行各业都会有这种情况的出现,但基本受影响的都是初、
录音功能是多媒体应用中的一个重要组成部分,未来可以进一步深入探索相关的处理和应用场景。C语言来实现使用鸿蒙5.0的OHAudio接口,开发一个简单的音频录制功能(包含详细的完整的程序和数据)_鸿蒙echarts资源-CSDN文库。C语言来实现使用鸿蒙5.0的OHAudio接口,开发一个简单的音频录制功能(包含详细的完整的程序和数据)_鸿蒙echarts资源-CSDN文库。语言来实现录音的启动、停止
CAP原则CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。分区性:数据一致性分布式事务协议——2PC假设没有错误情况下:假设其中某一参与者出错:不管最后结果如何,第二阶段都会结束当前事务分布式事务协议——
一.系统架构演变1.1. 集中式架构当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。存在的问题:代码耦合,开发维护困难无法针对不同模块进行针对性优化无法水平扩展单点容错率低,并发能力差1.2.垂直拆分当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求...
文章目录0)服务相关架构的演变*关于面向对象、面向组件、面向服务1)面向服务架构(SOA)1.1 什么是面向服务架构(SOA)?1.2 为什么需要SOA?1.3 SOA 的特征1.4 SOA 的实现方法1、Web Service2、服务注册表3、企业服务总线(ESB)1.5 SOA 的关键技术UDDIWSDLSOAPREST2)微服务架构2.1 什么是微服务架构?2.2 为什么需要微服务架构?背景
1.微服务和分布式是什么?首先我们必须清楚:微服务是架构设计方式;分布式有两种概念,即可指架构设计方式也可指系统部署方式。总结就是微服务分散能力 ;分布式分散压力下面为们具体讲解:1.1分布式分布式的核心思想就是拆。1.1.1分布式系统部署方式把服务进行拆分,分别部署到不同的机器上。分布式服务顾名思义服务是分散部署在不同的机器上的,一个服务可能负责几个功能,是一种面向SOA架构的,服务之间也是通过
作为一种采用分布式服务拆分业务逻辑,完成解耦的架构模式,微服务架构成为诸多企业数字化转型的利器之一。在从功能即服务、容器以及现在的 WebAssembly 中学到了一些东西之后,如何将这些技术与传统的微服务结合起来,我们不妨通过这篇一起来看看Fermyon是怎么做的?如果从微服务的功能定义开始,很可能把这种模式定义为通过网络进行通信的REST服务。但当谈到编写微服务的程序时,有一个严峻的现实摆在面
写在前面突入其来的新肺炎疫情打乱了节日生活的节奏,没有能力参与这场危机的社会救援,只能窝在家里不去给社会添乱了,在此向目前奋战的抗疫前线的每一位工作者致以崇高的敬意,是你们的勇敢和坚毅撑起了我们这个社会的脊梁!作为一名工作有年头了的软件技术工作者,这个时候也没什么可以做到,还是继续我以前的技术学习思路讲解的,希望能给那些跟我一样宅在家里,想学习Java编程技术提高自己的小伙伴们提高一些可以参考借鉴
一款你不得不了解的轻量级分布式任务调度系统!github地址:CronMan简介CronMan是一款轻量级的分布式任务调度系统。随着微服务化架构的逐步演进,单体架构逐渐演变为分布式、微服务架构,相应的也需要一个分布式任务调度系统来管理分布式架构中的定时任务。已有的分布式任务调度系统如:Saturn、elastic-job、xxl-job都是非常优秀的开源作品,为了学习与交流,我设计了一款轻量级的分
分布式事务是微服务的重点、难点,也是很多初中级开发工程师进阶的拦路虎,笔者将分布式事务分为三节介绍一下,从理论到实战,希望对你有所帮助。什么是分布式事务?分布式对应的是单体架构,互联网早起单体架构是非常流行的,好像是一个家族企业,大家在一个家里劳作,单体架构如下图:但是随着业务的复杂度提高,大家族人手不够,此时不得不招人,这样逐渐演变出了分布式服务,互相协作,每个服务负责不同的业务,架构如下图:因
写这篇文章为了更清楚自己技术能力,同时分享给大伙,看看自己技术水平位于哪里。个人能力有限,基于我所理解的知识来讲解一下:从程序员到大型分布式架构师,我们自己到底位于哪里。描述不当之处还请各路大佬点明,老弟也好更上一层楼!!!本人就以之前画的微服务系统架构图来逐一讲解。上一篇讲述了:Java程序员刻苦修炼锻造基础从程序员到大型分布式架构师,自己到底位于哪里(一)这一篇接着讲述……1.分布式服务治理方
为什么需要请求链路跟踪?随着业务的发展,单体架构变为微服务架构,并且系统规模也变得越来越大,各微服务间的调用关系也变得越来越复杂。在分布式系统中,一个集群中有几十个微服务;微服务调用微服务,一个或多个微服务的网络环境问题、硬件问题导致服务提供失败。在微服务框架中,一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果,在复杂的微服务架构系统中,几乎每一个前端请求都
对比微服务相比分布式服务来说,它的粒度更小,服务之间耦合度更低,由于每个微服务都由独立的小团队负责,因此它敏捷性更高,分布式服务最后都会向微服务架构演化,这是一种趋势, 不过服务微服务化后带来的挑战也是显而易见的,例如服务粒度小,数量大,后期运维将会很难。一、Dubbo与SpringCloud优缺点相同点:SpringCloud 和Dubbo可以实现RPC远程调用框架,可以实现服务治理。不同点:S
深入理解dubbo分布式服务框架/负载/容错/调优/高可用/面试摘要:作为和cloud二分微服务框架天下的dubbo,无论是面试,还是在项目中,屡屡用到,作为阿里生态的政采云,在项目中也用到了dubbo作为服务中间件。本文从介绍dubbo开始,层层递进,讲解其使用情况/核心技术/节点说明/底层原理/高可用/技术选型/面试踩坑。1、dubbo:分布式服务框架什么是dubbo?高性能和透明......
随着微服务分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如分布式服务、分布式数据库、分布式缓存等,使得后台服务构成了一种复杂的分布式网络。在服务能力提升的同时,复杂的网络结构也使问题定位更加困难。在一个请求在经过诸多服务过程中,出现了某一个调用失败的情况,查询具体的异常由哪一个服务引起的就变得十分抓狂,问题定位和处理效率是也会非常低。
为什么说要搞定微服务架构,先搞定RPC框架?原创:58沈剑架构师之路2016-08-25第一章聊了【“为什么要进行服务化,服务化究竟解决什么问题”】第二章聊了【“微服务的服务粒度选型”】今天开始聊一些微服务的实践,第一块,RPC框架的原理及实践,为什么说要搞定微服务架构,先搞定RPC框架呢?一、需求缘起服务化的一个好处就是,不限定服务的提供方使用什...
前言分布式服务框架不仅仅包含核心的运行时类库,还包括服务划分原则、服务化最佳实践、服务治理、服务监控、服务开发框架等,它是一套完整的解决方案,用来协助应用做服务化改造,以及指导用户如何构建适合自己业务场景的服务化体系,将服务化的价值发挥到极致。基于分布式服务框架,业务终于可以把全部精力都放到应用层的逻辑开发,研发效率、系统可靠性都得到了极大的提升。目前,华为电信软件主要解决方案几乎所有的Java系
分布式任务调度管理 Distribution task center. 支持Rabbit与kafka两种消息队列,实现立即执行与根据CronExpress表达式的执行及更加复杂的复合执行策略。在任务执行过程中可完成回滚操作。
前言先抛出一个问题大家思考一下:在分布式系统中,我们如何保证多个请求的顺序性问题,比如有A/B两个系统,系统A在一次订单业务处理中,向B系统发送三次请求,先进行插入订单操作,然后对订单状态进行修改,最后增加用户积分。但是这三次请求分别落在了不同的机器上,并且插入订单的操作由于一些意外导致延迟,修改订单操作先执行了,但是此时并没有订单信息,也就会出现我们期望之外的结果了。那面对这种情况我们应该如何避
自我理解集中式架构,垂直拆分,分布式服务,服务治理,微服务1 集中式架构a.是什么:单一程序,一个应用,将所有功能都部署在一起b.应用场景:网站流量很小时c.优点:减少部署节点和成本d.缺点:代码耦合,开发维护困难无法针对不同模块进行针对性优化无法水平扩展单点容错率低,并发能力差2 垂直拆分a.是什么:根据业务功能将系统拆分成多个程序b.应用场景...
1. 引言微服务已经成为当下最为流行的分布式架构了。通过将系统拆分成若干个服务,将业务进行横向、纵向切分,而诞生出各个高度内聚、轻度耦合的微服务,组成微服务架构。微服务架构在其可维护性、责任分工上都有着很大的优势,更加有利于系统的组建、维护、问题的快速响应和解决。但是,微服务架构也存在着难以治理的缺点,由于服务数量众多,每个服务又有多台服务器提供服务,如何实时监控每台服务器的运行健康情况,...