1 cityHome.vue新增一个属性：<template> <div> <home-header :city="city"></home-header> <home-swiper></home-swiper> <home-icons></home-icons>
1 Vue实例<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Vue实例</title> <script src='../vue.js'></script> </head
对组件功能的封装，可以像搭积木一样开发网页。Vue官方的示例图对组件化开发的形象展示。左边是一个网页，可以按照功能模块抽象成很多组件，这些组件就像积木一样拼接成网页。1 什么是组件化开发1.1 浏览器封装好的组件在页面的源码里写出的button标签，会在前端页面中显示如下样式：这button就是个组件，这样前端页面在显示上会加上边框和鼠标悬停样式，还可使用click事件触发函数等。只不过这是浏览器
1 JQ实现待办任务列表<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>TodoList Jquery</title> <script src='jquery.js'></script
讲解部分 Vue 基础语法，通过 TodoList 功能编写，在熟悉基础语法的基础上，扩展解析 MVVM 模式及前端组件化的概念及优势。1 案例1.1 下载安装https://v2.cn.vuejs.org/v2/guide/installation.html：1.2 原生实现打印<!DOCTYPE html> <html lang="en"> <head>
掌握Flink中三种常用的Time处理方式，掌握Flink中滚动窗口以及滑动窗口的使用，了解Flink中的watermark。Flink在流处理工程中支持不同的时间概念。1 处理时间（Processing time）执行相应算子操作的机器的系统时间。当流程序在处理时间运行时，所有基于时间的算子操作（如时间窗口）将使用运行相应算子的机器的系统时钟。每小时处理时间窗口将包括在系统时钟指示整个小时之间到
1 简介1.1 定义不要存在多于一个导致类变更的原因。1.2 特点一个类/接口/方法只负责一项职责。1.3 优点降低类的复杂度、提高类的可读性，提高系统的可维护性、降低变更引起的风险。类的复杂性降低，实现什么职责都有清晰明确定义可读性提高，复杂性降低，那当然可读性提高可维护性提高，可读性提高，更易维护变更引起的风险降低，变更必不可少。若接口的单一职责做好，一个接口修改只对相应的实现类有影响，对其他
1 概述ChannelHandlerContext 代表 ChannelHandler 和 ChannelPipeline 之间的关联，每当有 ChannelHandler 添加到 ChannelPipeline，都会创建 ChannelHandlerContext。1.1 主要功能管理它所关联的 ChannelHandler 和在同一个 ChannelPipeline 中的其他 ChannelH
1 概述把ChannelPipeline看成拦截流经Channel的入、出站事件的ChannelHandler 的实例链，就易看出这些 ChannelHandler 之间的交互如何组成一个应用程序数据和事件处理逻辑的核心。每个新建的 Channel 都会被分配一个新的 ChannelPipeline。这项关联是永久性的；Channel 既不能附加另外一个 ChannelPipeline，也不能分离
1 Channel 接口的生命周期Channel 定义了一组和 ChannelInboundHandler API 密切相关的简单但功能强大的状态模型1.1 Channel 的状态状 态描 述ChannelUnregisteredChannel 已经被创建，但还未注册到 EventLoopChannelRegisteredChannel 已经被注册到了 EventLoopChannelActive
针对打开首页接口的性能问题，前文中确定是Gateway在消耗响应时间，达到了近100毫秒。于是，我们开始定位Gateway上的响应时间消耗。第一阶段，关注应用所在的主机，了解到宿主机有四台第二阶段，查看物理机的CPU模式。尝试通过修改CPU运行模式来优化性能。可仍没解决，TPS没见提升，响应时间依旧很长进入第三阶段，继续分析其他瓶颈点，如wa cpu、资源均衡使用、网络带宽等问题。性能的分析逻辑里
1 下载下载 6.2.7 版本：[root@service-monitoring ~]# docker pull redis:6.2.7 6.2.7: Pulling from library/redis 025c56f98b67: Pull complete 060e65aed679: Pull complete b95291e865b7: Pull complete e3023c0b11
1 下载 MySQL我们就可以到 docker hub 来看：点击后的页面：直接执行docker pull mysql，会下载最新版本的 MySQL。点击 tags，找到并下载经典的 MySQL5.7：[root@service-monitoring ~]# docker pull mysql:5.7.42-oracle 5.7.42-oracle: Pulling from library
授权服务的核心：颁发访问令牌，而OAuth 2.0规范没有约束访问令牌内容的生成规则，只要符合：唯一性不连续性不可猜性可灵活选择令牌形式：既可是没有内部结构 && 不包含任何信息含义的随机字符串也可是具有内部结构 && 包含有信息含义的字符串以前生成令牌的方式都是默认一个随机字符串。而结构化令牌，目前用得最多的就是JWT令牌。1 简介JSON Web Token（J
HBase是一种基于Hadoop的分布式列存储数据库，它支持大规模结构化数据的存储和随机访问。在HBase中，扫描（Scan）是一种读取表中数据的方式，它可以返回表中满足条件的一部分或全部数据。本文将介绍HBase中扫描的概念、使用方法和性能优化。1 扫描的概念扫描是一种读取表中数据的方式，它可以按照一定的条件过滤出表中符合条件的一部分或全部数据，并返回给用户。HBase中的扫描是基于rowkey
1 架构演进的定义1.1 定义通过设计新的系统架构(4R)，来应对业务和技术的发展变化。1.2 关键点新架构新的复杂度1.3 目的应对业务和技术的发展变化后带来新的复杂度。案例淘宝去IOE，是因为业务发展大了后，IOE的成本和可控性难以满足，而非性能。架构重构 vs 架构演进技术手段不是区分架构重构和架构演进的方法，复杂度是否变化才是判断关键。2 架构演进的原则、驱动力、模式1个原则架构演进是为了
现象同样TPS低、响应时间长，但这个接口走的路径不一样，你将看到在资源真不足时，只有增加相应节点的资源才能提升性能。不要轻易给出资源不足的结论。因为但凡有优化空间，都要尝试优化，而不是直接告诉领导加资源。给“增加资源”结论，须建立在有足够证据基础上1 压力场景数据对查询商品接口，第一次试执行性能场景的结果：TPS只有250左右，且响应时间也明显随压力增加而增加，看起来瓶颈已出现？下一步看架构图。2
RESAR性能工程中，场景分为基准、容量、稳定性、异常。每类场景对应不同目标。基准场景是为找到系统中明显配置及软件Bug，也为容量场景提供可对比的基准数据。基准场景要有确定结论。线程数应该如何确定，压力线程的连续递增的重要性，以及如何将之前所讲的分析思路应用在具体的分析案例中。1 性能场景分类通常拿到的需求：评估系统能支持的最大容量。为知道当前的系统容量，目标很明确测试并优化系统以支持线上业务。有
程序设计语言指导怎样把设计更好地落地各种编程范式指导可以用什么样的元素去做设计设计原则与模式指导如何组合分解出来的各个元素分解组合的东西是从哪来？需要你对设计方法有一个基本的认知，要理解真实世界中，解决具体问题的过程。来谈谈设计方法，了解一下设计的基本过程。1 哪些设计方法有些人一上来会先设计DB，因为它们觉得，程序=数据+函数：数据呢，就要存到数据库里剩下的就是根据需要对数据库表进行增删改查这实
一些性能分析方法论，如SEI负载测试计划过程、RBI方法论、性能下降曲线分析法等，只是停留在概念和方法论，并无落地细节，它们完全没有必要存在。在任何一个搜索工具搜“性能测试方法论”关键字，基本上都可以看到很多复制来复制去的内容，基本都在描述一个测试的实施过程，并且这些实施过程也都基本停留在测试阶段。如下面几段关于“SEI负载测试计划过程”的描述：SEI load Testing Planning
1 痛点2 方案选型2.1 轮询拉取每个客户端定时轮询服务端，请求好友列表。缺点对移动端耗电、耗流量对服务端也是较大的资源浪费因为好友数据其实是不会频繁变化的，导致每次拉去的数据可能都是一样的。2.2 业务回调业务服务可以知道谁加了谁的，即可调用 IM 服务通知客户端拉取。缺点业务服务端和 IM 服务端需新增交互逻辑。数据同步强依赖于业务服务端，若回调过程任一节点失败，依旧无法同步通讯录。而且客户
1 Dubbo 整体架构设计dubbo-remoting 模块提供多种客户端和服务端通信功能。最底层部分即为 Remoting 层：包括 Exchange、Transport和Serialize 三层。本文主要描述 Exchange 和 Transport 两层。Dubbo直接集成已有的第三方网络库，如Netty、Mina、Grizzly 等 NIO 框架：dubbo-remoting-zooke
1 传统socket网络编程1.1 实战服务端：ServerBootpackage com.javaedge.netty.ch2;/** * @author JavaEdge */public class ServerBoot { private static final int PORT = 8000; public static void main(String[] args) {
分布式环境下，RPC框架自身以及服务提供方的业务逻辑实现，都应该对异常进行合理地封装，让使用方可以根据异常快速地定位问题；而在依赖关系复杂且涉及多个部门合作的分布式系统中，我们也可以借助分布式链路跟踪系统，快速定位问题。1 Future超时处理案例以调用端请求超时处理为例，RPC框架如何处理超时请求。无论同步、异步调用，调用端内部都是异步，调用端在向服务端发消息前会创建一个Future，存储消息标
深入RPC，更好使用RPC，须从RPC框架整体性能考虑问题。得知道如何提升RPC框架的性能、稳定性、安全性、吞吐量及如何在分布式下快速定位问题。RPC框架如何压榨单机吞吐量？1 前言TPS一直上不去，压测时CPU压到40%～50%就再也压不上去，TPS也不提高，咋办？看业务逻辑，在执行较为耗时的业务逻辑基础上，又同步调用了好几个其它服务。由于这几个服务的耗时较长，导致服务业务逻辑耗时也长，CPU大
应对突发流量，限流是好手段，但还有其它手段，可最大限度保障业务无损。1 为何分组若在接口上再加一个分组维度去管理，不就让接口复杂了？实则不然，比如无汽车年代，道路很简单，就一条，行人、洋车都在上边走。那随着汽车普及，道路越来越宽，有高速、辅路、人行道。交通网的建设与完善不仅提高出行效率，还更好保障行人安全。RPC治理也一样。假设你是一个服务提供方应用的负责人，早期业务量不大，应用之间的调用关系简单
RPC面临高并发场景，提供服务的每个节点就都可能由于访问量过大而异常，如业务处理耗时过长、CPU飘高、频繁Full GC以及服务进程直接宕机。要保证服务稳定性和高可用性，就要业务自我保护。使用RPC时，业务如何自我保护？最常见的限流。RPC调用包括服务端和调用端，调用端向服务端发起调用。服务端与调用端分别是如何进行自我保护的。1 服务端自保要发布一个RPC服务，作为服务端接收调用端发过来的请求，这
0 前言应用启动居然也这么“讲究”？好比我们日常生活中的热车，行驶之前让发动机空跑一会，可以让汽车的各个部件都“热”起来，减小磨损。运行了一段时间后的应用，执行速度会比刚启动的应用更快。因为Java里，运行过程中，JVM把高频代码编译成机器码，被加载过的类会被缓存到JVM缓存，再使用时不会触发临时加载，使“热点”代码执行不用每次都通过解释，提升了执行速度。但这些“临时数据”都在重启后消失了。重启后
1 连接模型的传输协议依赖 TCP 提供从客户端到服务器端间的连接。早期 使用一个简单模型处理这样的连接。这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新连接，收到应答时立即关闭。这简单模型对性能有先天限制：打开每个 TCP 连接都相当耗费资源。客户端、服务器端间需交换好多消息。当请求发起时，网络延迟和带宽都会对性能影响。现代浏览器往往要发起很多次请求(十几个或更多)才
1 简介SPI，Service Provider Interface，一种服务发现机制：有了SPI，即可实现服务接口与服务实现的解耦：服务提供者（如 springboot starter）提供出 SPI 接口。身为服务提供者，在你无法形成绝对规范强制时，适度"放权" 比较明智，适当让客户端去自定义实现客户端（普通的 springboot 项目）即可通过本地注册的形式，将实现类注册到服务端，轻松实现
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
