• 关于

    依赖的传递性

    的搜索结果

回答

详细解答可以参考官方帮助文档该解决方案适用的移动云产品包括: 移动推送HTTPDNS移动热修复移动用户反馈移动加速移动数据分析 1. 什么是UTDID冲突? Android UTDID包命名形式为:utdid4all-x.x.x.jar,iOS UTDID包命名格式为:UTDID.framework。 UTDID作为阿里集团移动端SDK通用组件,包括阿里云在内的许多平台产品移动端SDK对其有依赖,若同时集成多平台移动端SDK,可能发生UTDID冲突。 2. 怎么解决UTDID冲突? 【注意】Android UTDID版本号必须>= v1.1.5.3,若不能确认UTDID版本号,请参考下述方案,保留阿里云平台的UTDID包。 2.1 手动集成解决方案 手动删除重复的UTDID SDK,仅保留一个UTDID SDK。建议保留阿里云平台下载的UTDID SDK。 2.2 远程仓库集成解决方案 Android集成时,可以通过exclude关闭其他产品SDK对UTDID的传递性依赖,示例如下所示: compile ('com.xxx:xxx.xxx:1.0.1') { exclude (module: 'utdid4all')} 其module名不一定为utdid4all,具体如何关闭UTDID的传递性依赖,可咨询对应产品SDK接口人。 iOS集成时,如果通过CocoaPods进行远程仓库依赖,由于CocoaPods无法关闭传递性依赖,SDK集成需要修改为手动集成。 2.3 与支付宝SDK UTDID冲突 支付宝SDK是通过源码方式集成的UTDID,所以不适用于上述的手动集成解决方案和远程仓库集成解决方案。可下载并集成 剥离UTDID的支付宝SDK,保留阿里云平台的UTDID包。该版本SDK和通用支付宝SDK保持同步更新,无需担心支付宝相关功能受影响。

2019-12-01 23:32:20 0 浏览量 回答数 0

问题

阿里云-移动云产品SDK UTDID冲突解决方案

猫饭先生 2019-12-01 22:07:42 1255 浏览量 回答数 0

问题

移动推送: 与支付宝的包出现UTDID冲突的解决办法有哪些?

猫饭先生 2019-12-01 21:58:39 1148 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

移动推送: 与支付宝的包出现UTDID冲突的解决办法

猫饭先生 2019-12-01 21:58:24 1191 浏览量 回答数 0

回答

Mixin的缺陷: 组件与Mixin之间存在隐式依赖(Mixin经常依赖组件的特定⽅法,但在定义组件时并不知道这种依赖关系)多个Mixin之间可能产⽣冲突(⽐如定义了相同的state字段)Mixin倾向于增加更多状态,这降低了应⽤的可预测性(The more state in your application, the harder it is to reason about it.),导致复杂度剧增隐式依赖导致依赖关系不透明,维护成本和理解成本迅速攀升: 难以快速理解组件⾏为,需要全盘了解所有依赖Mixin的扩展⾏为,及其之间的相互影响组价⾃身的⽅法和state字段不敢轻易删改,因为难以确定有没有Mixin依赖它Mixin也难以维护,因为Mixin逻辑最后会被打平合并到⼀起,很难搞清楚⼀个Mixin的输⼊输出 HOC相⽐Mixin的优势: HOC通过外层组件通过Props影响内层组件的状态,⽽不是直接改变其State不存在冲突和互相⼲扰,这就降低了 耦合度不同于Mixin的打平+合并,HOC具有天然的层级结构(组件树结构),这⼜降低了复杂度 HOC的缺陷: 扩展性限制: HOC⽆法从外部访问⼦组件的State因此⽆法通过shouldComponentUpdate滤掉不必要的更新,React在⽀持ES6 Class之后提供了React.PureComponent来解决这个问题Ref传递问题: Ref被隔断,后来的React.forwardRef来解决这个问题Wrapper Hell:HOC可能出现多层包裹组件的情况,多层抽象同样增加了复杂度和理解成本命名冲突: 如果⾼阶组件多次嵌套,没有使⽤命名空间的话会产⽣冲突,然后覆盖⽼属性不可⻅性: HOC相当于在原有组件外层再包装⼀个组件,你压根不知道外层的包装是啥,对于你是⿊盒 Render Props优点: 上述HOC的缺点Render Props都可以解决 Render Props缺陷: 使⽤繁琐: HOC使⽤只需要借助装饰器语法通常⼀⾏代码就可以进⾏复⽤,Render Props⽆法做到如此简单嵌套过深: Render Props虽然摆脱了组件多层嵌套的问题,但是转化为了函数回调的嵌套 React Hooks优点: 简洁: React Hooks解决了HOC和Render Props的嵌套问题,更加简洁解耦: React Hooks可以更⽅便地把 UI 和状态分离,做到更彻底的解耦组合: Hooks 中可以引⽤另外的 Hooks形成新的Hooks,组合变化万千函数友好: React Hooks为函数组件⽽⽣,从⽽解决了类组件的⼏⼤问题: this指向容易错误分割在不同声明周期中的逻辑使得代码难以理解和维护代码复⽤成本⾼(⾼阶组件容易使代码量剧增) React Hooks缺陷: 额外的学习成本(Functional Component 与Class Component之间的困惑)写法上有限制(不能出现在条件、循环中),并且写法限制增加了重构成本破坏了PureComponent、React.memo浅⽐较的性能优化效果(为了取最新的props和state,每次render()都要重新创建事件处函数)在闭包场景可能会引⽤到旧的state、props值内部实现上不直观(依赖⼀份可变的全局状态,不再那么“纯”)React.memo并不能完全替代shouldComponentUpdate(因为拿不到state change,只针对 props change)

前端问答 2019-12-02 03:24:17 0 浏览量 回答数 0

问题

阿里云消息队列(MQS)免费试用

chinese 2019-12-01 21:31:05 14545 浏览量 回答数 14

回答

IoC(Inversion of Control) (1). IoC(Inversion of Control)是指容器控制程序对象之间的关系,而不是传统实现中,由程序代码直接操控。控制权由应用代码中转到了外部容器,控制权的转移是所谓反转。 对于Spring而言,就是由Spring来控制对象的生命周期和对象之间的关系;IoC还有另外一个名字——“依赖注入(Dependency Injection)”。从名字上理解,所谓依赖注入,即组件之间的依赖关系由容器在运行期决定,即由容器动态地将某种依赖关系注入到组件之中。 (2). 在Spring的工作方式中,所有的类都会在spring容器中登记,告诉spring这是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制,也就是说控制对象生存周期的不再是引用它的对象,而是spring。对于某个具体的对象而言,以前是它控制其他对象,现在是所有对象都被spring控制,所以这叫控制反转。(3). 在系统运行中,动态的向某个对象提供它所需要的其他对象。 (4). 依赖注入的思想是通过反射机制实现的,在实例化一个类时,它通过反射调用类中set方法将事先保存在HashMap中的类属性注入到类中。 总而言之,在传统的对象创建方式中,通常由调用者来创建被调用者的实例,而在Spring中创建被调用者的工作由Spring来完成,然后注入调用者,即所谓的依赖注入or控制反转。 注入方式有两种:依赖注入和设置注入; IoC的优点:降低了组件之间的耦合,降低了业务对象之间替换的复杂性,使之能够灵活的管理对象。AOP(Aspect Oriented Programming)(1). AOP面向方面编程基于IoC,是对OOP的有益补充;(2). AOP利用一种称为“横切”的技术,剖解开封装的对象内部,并将那些影响了 多个类的公共行为封装到一个可重用模块,并将其名为“Aspect”,即方面。所谓“方面”,简单地说,就是将那些与业务无关,却为业务模块所共同调用的 逻辑或责任封装起来,比如日志记录,便于减少系统的重复代码,降低模块间的耦合度,并有利于未来的可操作性和可维护性。(3). AOP代表的是一个横向的关 系,将“对象”比作一个空心的圆柱体,其中封装的是对象的属性和行为;则面向方面编程的方法,就是将这个圆柱体以切面形式剖开,选择性的提供业务逻辑。而 剖开的切面,也就是所谓的“方面”了。然后它又以巧夺天功的妙手将这些剖开的切面复原,不留痕迹,但完成了效果。(4). 实现AOP的技术,主要分为两大类:一是采用动态代理技术,利用截取消息的方式,对该消息进行装饰,以取代原有对象行为的执行;二是采用静态织入的方式,引入特定的语法创建“方面”,从而使得编译器可以在编译期间织入有关“方面”的代码。(5). Spring实现AOP:JDK动态代理和CGLIB代理 JDK动态代理:其代理对象必须是某个接口的实现,它是通过在运行期间创建一个接口的实现类来完成对目标对象的代理;其核心的两个类是InvocationHandler和Proxy。 CGLIB代理:实现原理类似于JDK动态代理,只是它在运行期间生成的代理对象是针对目标类扩展的子类。CGLIB是高效的代码生成包,底层是依靠ASM(开源的java字节码编辑类库)操作字节码实现的,性能比JDK强;需要引入包asm.jar和cglib.jar。 使用AspectJ注入式切面和@AspectJ注解驱动的切面实际上底层也是通过动态代理实现的。(6). AOP使用场景: Authentication 权限检查 Caching 缓存 Context passing 内容传递 Error handling 错误处理 Lazy loading 延迟加载 Debugging  调试 logging, tracing, profiling and monitoring 日志记录,跟踪,优化,校准 Performance optimization 性能优化,效率检查 Persistence  持久化 Resource pooling 资源池 Synchronization 同步 Transactions 事务管理 另外Filter的实现和struts2的拦截器的实现都是AOP思想的体现。

wangccsy 2019-12-02 01:50:38 0 浏览量 回答数 0

回答

DES是Data Encryption Standard(数据加密标准)的缩写。它是由IBM公司研制的一种加密算法,美国国家标准局于1977年公布把它作为非机要部门使用的数据加密标准,二十年来,它一直活跃在国际保密通信的舞台上,扮演了十分重要的角色[10]。 DES是一个分组加密算法,他以64位为分组对数据加密。同时DES也是一个对称算法:加密和解密用的是同一个算法。它的密匙长度是56位(因为每个第8位都用作奇偶校验),密匙可以是任意的56位的数,而且可以任意时候改变。其中有极少量的数被认为是弱密匙,但是很容易避开他们。所以保密性依赖于密钥。 DES算法是一种分组密码,通过反复使用加密组块替代和换位两种技术,经过16轮的变换后得到密文,安全性很高。DES属于传统的对称密码体制,其加密密钥与解密密钥是相同的,由于其安全性高,计算较简单,所以一度攻获得广泛使用。 DES算法的优点:适用于一对一的信息交换,加密速度快。 DES算法的缺点:密钥的传递和管理困难,不适用于大量用户的情况,因此不适用于EC即电子商务交易中。 RSA加密算法:1978年就出现了这种算法,它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作,也很流行。算法的名字以发明者的名字命名:Ron Rivest, AdiShamir 和 Leonard Adleman。但RSA的安全性一直未能得到理论上的证明。 RSA的安全性依赖于大数分解。公钥和私钥都是两个大素数(大于 100个十进制位)的函数据猜测,从一个密钥和密文推断出明文的难度等同于分解两个大素数的积。 RSA 的安全性:依赖于大数分解,但是否等同于大数分解一直未能得到理论上的证明,因为没有证明破解RSA就一定需要作大数分解。假设存在一种无须分解大数的算法,那它肯定可以修改成为大数分解算法。目前, RSA的一些变种算法已被证明等价于大数分解。不管怎样,分解n是最显然的攻击方法。 RSA的速度:由于进行的都是大数计算,使得RSA最快的情况也比DES慢上100倍,无论是软件还是硬件实现。速度一直是RSA的缺陷。一般来说只用于少量数据加密。 RSA的缺点主要有: 1产生密钥很麻烦,受到素数产生技术的限制,因而难以做到一次 一密。2 分组长度太大,为保证安全性,至少也要 600 bits 以上,使运算代价很高,尤其是速度较慢,较对称密码算法慢几个数量级;且随着大数分解技术的发展,这个长度还在增加,不利于数据格式的标准化。目前,SET(Secure Electronic Transaction)协议中要求CA采用2048比特长的密钥,其他实体使用1024比特的密钥。

琴瑟 2019-12-02 01:27:16 0 浏览量 回答数 0

回答

新地址 24题 Starters可以理解为启动器,它包含了一系列可以集成到应用里面的依赖包,你可以一站式集成 Spring 及其他技术,而不需要到处找示例代码和依赖包。如你想使用 Spring JPA 访问数据库,只要加入 spring-boot-starter-data-jpa 启动器依赖就能使用了。Starters包含了许多项目中需要用到的依赖,它们能快速持续的运行,都是一系列得到支持的管理传递性依赖。 23题 Spring Boot 的核心配置文件是application(.yml 或者 .properties) 和 bootstrap(.yml 或者 .properties) 配置文件。boostrap 由父 ApplicationContext 加载,比 applicaton 优先加载,boostrap 里面的属性不能被覆盖。application 配置文件主要用于 Spring Boot 项目的自动化配置。bootstrap 配置文件的应用场景:使用 Spring Cloud Config 配置中心时,这时需要在 bootstrap 配置文件中添加连接到配置中心的配置属性来加载外部配置中心的配置信息;一些固定的不能被覆盖的属性;一些加密/解密的场景。 22题 优点:快速构建项目;对主流开发框架的无配置集成;starters自动依赖与版本控制;大量的自动配置,简化开发,也可修改默认值;无需配置XML,无代码生成,开箱即用;项目可独立运行,无须外部依赖Servlet容器;提供运行时的应用监控;与云计算的天然集成。缺点:集成度较高,使用过程中不太容易了解底层。 21题 Spring Boot的初衷就是为了简化spring的配置,使得开发中集成新功能时更快,简化或减少相关的配置文件。Spring Boot其实是一个整合很多可插拔的组件(框架),内嵌了使用工具(比如内嵌了Tomcat、Jetty等),方便开发人员快速搭建和开发的一个框架。 20题 当程序创建对象、数组等引用类型实体时,系统会在堆内存中为之分配一块内存区,对象就保存在内存区中,不需要显式的去释放一个对象的内存,而是由虚拟机自行执行。在JVM 中,有一个垃圾回收线程,它是低优先级的,在正常情况下是不会执行的,只有在虚拟机空闲或者当前堆内存不足时,才会触发执行,标记那些没有被任何引用的对象,并将它们添加到要回收的集合中,进行回收。 19题 HashMap线程不安全,HashTable线程安全。HashMap允许有一个key为null,多个value为null;而HashTable不允许key和vale为null。继承类不一样,HashMap继承的是AbstractMap,HashTable继承的是Dictionary。初始容量不一样。使用的hashcode不一样。内部遍历方式的实现不一样。 18题 作用:内容可见性和禁止指令重排。内存可见性:某线程对 volatile 变量的修改,对其他线程都是可见的,即获取 volatile 变量的值都是最新的;禁止指令重排:重排序在单线程下一定能保证结果的正确性,但是在多线程环境下,可能发生重排序影响结果,若用volatile修饰共享变量,在编译时,会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。使用:当一个线程需要立刻读取到另外一个线程修改的变量值的时候,我们就可以使用volatile。区别:volatile是变量修饰符,而synchronized则作用于一段代码或者方法;volatile只是在线程内存和main memory(主内存)间同步某个变量的值,而synchronized通过锁定和解锁某个监视器同步所有变量的值。显然synchronized要比volatile消耗更多资源;synchronized 关键字可以保证变量原子性和可见性,volatile 不能保证原子性。 17题 非公平主要表现在获取锁的行为上,并非是按照申请锁的时间前后给等待线程分配锁的 ,每当锁被释放后 ,任何一个线程都有机会竞争到锁,这样做的目的是为了提高执行性能 ,缺点是可能会产生线程饥饿现象 。 16题 如果线程遇到了 IO 阻塞,无能为力,因为IO是操作系统实现的,Java代码并没有办法直接接触到操作系统。如果线程因为调用 wait()、sleep()、或者 join()方法而导致的阻塞,可以中断线程,并且通过抛出 InterruptedException 来唤醒它。 15题 原子操作就是无法被别的线程打断的操作。要么不执行,要么就执行成功。在Java中可以通过锁和循环CAS的方式来实现原子操作。从JDK 1.5开始提供了java.util.concurrent.atomic包,这个包中的原子操作类提供了一种用法简单、性能高效、线程安全地更新一个变量的方式。 14题 wait()是Object类的方法,所以每一个对象能使用wait()方法。sleep()是Thread类中的静态方法。sleep不会释放锁,但会让出cpu,sleep会在指定的休眠时间后自动唤醒。wait则会释放锁,让出系统资源,并且加入wait set中,wait不会自动唤醒,而需要notify()或者notifyAll()唤醒。sleep和wait都可以被中断,使用sleep需要捕获异常。wait与notify、notifyAll只能在同步代码块中使用,而sleep可以在任何地方使用。 13题 Synchronized 是由 JVM 实现的一种实现互斥同步的一种方式,查看编译后的字节码,会发现被 Synchronized 修饰过的程序块,在编译前后被编译器生成了monitorenter 和 monitorexit 两个字节码指令。在虚拟机执行到 monitorenter 指令时,首先要尝试获取对象的锁:如果这个对象没有锁定,或者当前线程已经拥有了这个对象的锁,把锁的计数器+1;当执行 monitorexit 指令时将锁计数器-1;当计数器为0时,锁就被释放了。如果获取对象失败了,那当前线程就要阻塞等待,直到对象锁被另外一个线程释放为止。Java 中 Synchronize 通过在对象头设置标记,达到了获取锁和释放锁的目的。 12题 Mybatis 通过动态代理,为需要拦截的接口生成代理对象以实现接口方法拦截功能,每当执行这 4 种接口对象的方法时,就会进入拦截方法,具体就是InvocationHandler 的 invoke()方法,只会拦截那些你指定需要拦截的方法。 实现方法:1.编写Intercepror接口的实现类;2.设置插件的签名,告诉mybatis拦截哪个对象的哪个方法;3.最后将插件注册到全局配置文件中。 11题 Mybatis可以映射枚举类,不单可以映射枚举类,Mybatis可以映射任何对象到表的一列上。映射方式为自定义一个TypeHandler,实现TypeHandler的setParameter()和getResult()接口方法。TypeHandler 有两个作用,一是完成从 javaType至jdbcType 的转换,二是完成jdbcType至javaType的转换,体现为 setParameter()和getResult()两个方法,分别代表设置sql问号占位符参数和获取列查询结果。 10题 Mybatis使用RowBounds对象进行分页,也可以直接编写sql实现分页,也可以使用Mybatis的分页插件。分页插件的原理:使用Mybatis提供的插件接口,实现自定义插件,在插件的拦截方法内拦截待执行的sql,然后重写sql,根据dialect方言,添加对应的物理分页语句和物理分页参数。举例:select * from student,拦截 sql 后重写为:select t.* from(select * from student)t limit 0,10。 9题 resultType和resultMap都是表示数据库表与pojo之间的映射规则的。类的名字和数据库相同时,可以直接设置resultType 参数为Pojo类。若不同或者有关联查询,需要设置resultMap将结果名字和Pojo名字进行转换。在项目中我们定义的resultMap多了property和column属性,实际也就是分别配置Pojo类的属性和对应的表字段之间的映射关系,多了这个映射关系以后,方便维护。 8题 之所以说Mybatis半自动化,是因为SQL语句需要用户自定义,SQL的解析、执行等工作由Mybatis执行。区别:Hibernate属于全自动 ORM 映射工具,使用Hibernate查询关联对象或者关联集合对象时,可以根据对象关系模型直接获取,所以它是全自动的。而 Mybatis 在查询关联对象或关联集合对象时,需要手动编写 sql 来完成,所以它是半自动ORM映射工具。 7题 MyBatis 的缓存分为一级缓存和二级缓存。一级缓存是SqlSession级别的缓存,默认就有,在操作数据库时需要构造 sqlSession对象,在对象中有一个(内存区域)数据结构(HashMap)用于存储缓存数据,不同的sqlSession之间的缓存数据区域(HashMap)是互相不影响的。二级缓存是mapper级别的缓存,默认是不打开的,多个SqlSession去操作同一个Mapper的sql语句,多个SqlSession去操作数据库得到数据会存在二级缓存区域,多个SqlSession可以共用二级缓存,二级缓存是跨SqlSession的。 6题 RequestMapping是一个用来处理请求地址映射的注解,可用于类或方法上。用于类上,表示类中的所有响应请求的方法都是以该地址作为父路径。用于方法上是为了细化映射,即根据特定的HTTP请求方法(GET、POST 方法等)、HTTP请求中是否携带特定参数等条件,将请求映射到匹配的方法上。 5题 1、前置通知(before advice):在目标方法调用之前执行; 2、后置通知(after returning advice):在目标方法调用之后执行,一旦目标方法产生异常不会执行; 3、最终通知(after(finally) advice):在目标调用方法之后执行,无论目标方法是否产生异常,都会执行; 4、异常通知(after throwing advice):在目标方法产生异常时执行; 5、环绕通知(around advice):在目标方法执行之前和执行之后都会执行,可以写一些非核心的业务逻辑,一般用来替代前置通知和后置通知。 4题 1、通过构造器或工厂方法创建Bean实例;2、为Bean的属性设置值和对其他Bean的引用;3、将Bean实例传递给Bean后置处理器的postProcessBeforeInitialization方法;4、调用Bean的初始方法(init-method);5、将bean实例传递给bean后置处理器的postProcessAfterInitialization方法;6、bean可以使用了;7、当容器关闭时,调用Bean的销毁方法(destroy-method) 3题 在TransactionDefinition接口中定义了五个表示隔离级别的常量: ISOLATION_DEFAULT:使用后端数据库默认的隔离级别,Mysql默认采用的REPEATABLE_READ隔离级别;Oracle默认采用的READ_COMMITTED隔离级别。 ISOLATION_READ_UNCOMMITTED:最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。 ISOLATION_READ_COMMITTED:允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生 ISOLATION_REPEATABLE_READ:对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。 ISOLATION_SERIALIZABLE:最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。 2 题 自动装配提供五种不同的模式供Spring容器用来自动装配beans之间的依赖注入: 1.默认的方式是不进行自动装配,通过手工设置ref 属性来进行装配bean。 2.byName:通过参数名自动装配,之后容器试图匹配、装配和该bean的属性具有相同名字的bean。 3.byType:按照参数的数据类型进行自动装配,之后容器试图匹配和装配和该bean的属性类型一样的bean。如果存在多个相同类型的bean对象,会出错。 4.constructor:使用构造方法完成对象注入,其实也是根据构造方法的参数类型进行对象查找,相当于采用byType的方式。 5.autodetect:如果找到默认的构造函数,则通过 constructor的方式自动装配,否则使用 byType的方式自动装配。在Spring3.0以后的版本此模式已被废弃,已经不再合法了。 1 题 循环依赖只会存在在单例实例中,多例循环依赖直接报错。Spring先用构造器实例化Bean对象,然后将实例化结束的对象放到一个Map中,并且Spring提供获取这个未设置属性的实例化对象的引用方法。当Spring实例化了A类、B类后,紧接着会去设置对象的属性,此时发现A类依赖B类,就会去Map中取出已经存在的单例B类对象,以此类推。因为所持有的都是引用,所以A类一改变B类也会跟着改变。从而解决循环依赖问题。

游客ih62co2qqq5ww 2020-03-03 18:05:36 0 浏览量 回答数 0

回答

Django代码注意 1、模板标签里面 extend和include是冲突的,有了extend,include无法生效,原因:是底层渲染独立机制设计导致。 2、#coding:utf-8 这句只有放在代码文件第一行才能生效,放在注释字符串后面可能会失效。 3、由于前端发展而导致的Post请求Rest化和Django原生的技术设施层简化还有事务封装前移,由此产生的结果是业务层完全可以放在views里面。同事Restful化的好处就是可以把跨业务模块调用放在前端,保证了后端模块之间的正切 4、有用户自生成富文本内容的页面上最好不要放置带XSRF的POST表单,前者可能会窃取后者的Token信息。 5、在template里面的==这一类比较逻辑运算符号两边必须有空格,否则影响模板解析 6、form.is_valid内部逻辑中的Clean_data处理中抛出的异常不会向外传递,只会变成form.is_valid()返回false. 7、Django的业务层和View层怎么切分这个问题,一个简单的方法就是给业务层传递什么层级的参数,个人觉得传递验证过的form比较合适。 8、多级if else的两个简化技巧:1是直接用except处理;2是该半路return的直接return掉,这样做虽然不符合过程编程函数设计原则,但是代码相对简洁了很多。 9、Ubuntu生产环境下不能Print Unicode中文,否则会导致error. 10、因为DJango的500机制和事务机制,所以Django的View层对异常处理代码的依赖比较弱。 11、model form定义:没有在前端页面出现的字段,一定要exclude掉或者Null了,不过Null会影响默认值,所以最好的方法是Exclude掉,否则即便blank掉,也会导致form存储时出错。因为表单中字段不出现会把默认值覆盖成Null。 比exclude更方便的定义方式是定义fields元信息,这样model添加不用的字段不用跑来重新更新form定义 12、数据库存时区性数据的格式化显示一定要放在template里面用date之类的过滤器操作,如果用datetime的striftime直接格式化,会导致时区性数据丢失,出来的时间成了格林威治时间值了,如果在代码中strifttime处理,可以先用django.utils.timezone.localtime方法处理一下,这样出来的时间才是正常的 13、Django调试中的一个问题:众所周知,runserver启动,改动代码,服务会重启,但是改动自定义标签代码,服务是不会重启的。 14、form验证的errors在比较旧的版本里面是没有文本信息,前一段时间看文档,发现新版本有对errors有所加强,比较好用的比如as_json()和as_text(),两个方法,我在比较旧的版本中是自己写个函数对errors对象做解析生成反馈文本信息。 15、ManyToMany字段的through不能add or remove,为了扩展性的考虑,建议默认都加上through,可以为中间关系表加个date_added字段,顺便都加上unique_together约束,不过用through是有缺陷的:写操作略麻烦。那么如果你没加through,准备改成加through的,应该怎样最小改动的操作哪,应该是先把这个ManyToMany字段删除掉,并且migrate生效,然后再加一个有through的ManyToMany字段,当然了后台的数据还的备份重生效一次。这应该算是目前Django Migration特性的一个缺陷。 答案来源网络,供参考,希望对您有帮助

问问小秘 2019-12-02 03:02:13 0 浏览量 回答数 0

问题

maven依赖传递有效性?报错

爱吃鱼的程序员 2020-06-14 18:45:21 0 浏览量 回答数 1

回答

怎么 没人来呀 @中山野鬼###### 1、如果想去掉while(true),可以考虑通知实现; 2、关于自动重连的问题,可以考虑重发送逻辑中抽离出来,采用心跳检测完成; 3、另外发送速率统计部分也应该抽离出来。 4、上多通道要考虑资源使用可控。 5、实在不行按照业务拆分成多模块,用redis 或mq类的扩展一下架构设计; ######回复 @OS小小小 : map =(Map)JSONObject.parse(SendMsgCMPP2ThredPoolByDB.ZhangYi.take()); 换成take,阻塞线程,试试。######回复 @OS小小小 : 1、通知只是告知队列里有新的数据需要处理了; 5、内存队列换成redis队列 实现成本增加,但是可扩展性增加;######1、通知实现的话 ,岂不是 无法保证 最少发送么,又会陷入另一个问题中 是吗? 或者是我的想法不对么? 2、嗯,这一块可以这样做。谢谢你 3、速率统计这里 我目前想不到怎么抽离、既可以控制到位,又可以保证不影响。。。 5、redis 是有的 但是 redis的队列的话 跟我这个 没啥区别吧,可能速度更快一点。######while(true) 里面 没数据最起码要休眠啊,不停死循环操作,又没有休眠cpu不高才怪######回复 @OS小小小 : 休眠是必须的,只是前面有数据进来,可以用wait notify 的思路通知,思路就是这样,CountDownLatch 之类多线程通讯也可以实现有数据来就能立即处理的功能######嗯,目前在测试 排除没有数据的情况,所以这一块没有去让他休眠,后面会加进去。 就针对于目前这种情况,有啥好办法吗###### 我的思路是:一个主线程,多个任务子线程。 主线程有一层while(true),这个循环是不断的扫描LinkedBlockingQueue是否有数据,有则交个任务子线程(也就是你这里定义的线程池)处理,而不是像你这样每个子任务线程都有一个while(true) ######这才是对的做法######嗯,这思路可以。谢谢哈###### 引用来自“K袁”的评论 我的思路是:一个主线程,多个任务子线程。 主线程有一层while(true),这个循环是不断的扫描LinkedBlockingQueue是否有数据,有则交个任务子线程(也就是你这里定义的线程池)处理,而不是像你这样每个子任务线程都有一个while(true) 正确做法. 还有就是 LinkedBlockingQueue 本身阻塞的,while(true)没问题,主要在于不需要每个发送线程都去block######while(true)不加休眠就会这样###### java 的线程数量大致要和cpu数量一致,并不是越多越快,线程调度是很消耗时间的。要用好多线程,就需要设计出好的多线程业务模型,不恰当的sleep和block是性能的噩梦。利用好LinkedBlockingQueue,队列空闲时读队列的线程会释放cpu。利用消息触发后续线程工作,就没必要使用while(true)来不停的扫描。 ######@蓝水晶飞机 看到你要比牛逼,我就没有兴趣跟你说话了######回复 @不日小鸡 : 我就是装逼怎么啦,特么的装逼装出样子来的,起码也比你牛逼啊。######回复 @蓝水晶飞机 : 你说这话不能掩盖你没有回复我的问题又来回复我导致装逼失败的事实。 那你不是楼主你回复我干什么,还不是回答我的问题。 不要装逼了好么,装多就成傻逼了######回复 @不日小鸡 : 此贴楼主不是你,装什么逼。######回复 @王斌_ : 这些我都知道,我的意思是你这样回复可能会误导其他看帖子的人或者新手,让他们以为线程数就等于CPU数###### 引用来自“OS小小小”的评论 怎么 没人来呀 @中山野鬼 抬举我了。c++ 我还敢对不知深浅的人说,“权当我不懂”,java真心只是学过,没有实际工程上的经验。哈。而且我是c的思维,面对c适合的应用开发,是反对使用线程的。基本思维是,执行模块的生命周期不以任务为决定,同类的执行模块,可根据物理硬核数量,形成对应独立多个进程,但绝对不会同类的任务独立对应多个线程。哈。所以java这类面向线程的设计,没办法参与讨论。设计应用目标不同,系统组织策略自然有异。 唯一的建议是:永远不要依赖工具,特别是所谓的垃圾资源处理回收机制,无论它做的再好,一旦你依赖,必然你的代码,在不久的将来会因为系统设计规模的变大,而变的垃圾。哈。 听不懂的随便喷,希望听懂的,能记得这个观点,这不是我一个人的观点。 ######给100万像素做插值运算进行染色特效,请问单线程怎么做比多线程快?###### @乌龟壳 : 几种方法都可以,第一是按照计算步骤,每个进程处理一个步骤,然后切换共享空间(这没有数据传递逻辑上的额外开销),就是流水思维。第二个是block的思维,同样的几个进程负责相同计算,但负责不同片区。同时存在另一类的进程是对前期并发处理完的工作进行边界处理。 你这个例子体现不出进程和线程的差异的。 如果非要考虑进程和线程在片内cache的差异,如果没记错(错了大家纠正哈),进程之间的共享是在二级缓存之间吧。即便线程能做到一级缓存之间的共享,但对于这种大批量像素的计算,用进程仍然是使用 dma,将数据成块载入一级缓存区域进行处理,而这个载入工作和计算工作是同步的。不会有额外太多的延迟。 你举的这个例子,还真好是我以前的老本行。再说了。像素计算,如今都用专用计算处理器了吧。还用x86或arm来处理,不累死啊。哈。 而且这种东西java不适合,同样的处理器,用c写,基本可以比java快1到2倍。因为c可以直接根据硬件特性和计算逻辑特点有效调度底层硬件驱动方式。而java即便你用了底层优化的官方库,仍然不能保证硬件与计算目标特性的高度整合。 ######回复 @中山野鬼 : 简单来说,你的多个进程处理结果进行汇总的时候,是不是要做内存复制操作?如果是多线程天然就不用,多进程用系统的共享内存机制也不用,问题是既然用了共享内存,和多线程就没区别了。######回复 @乌龟壳 : 两回事哦。共享空间是独立的,而线程如果我没记错,全局变量,包括文件内的(静态变量)是共享的。不同线程共享同一个进程内的变量嘛。这些和业务逻辑相关的东西,每个线程又是独立一套业务逻辑,针对c语言,这样去设计,不是没事找事嘛。面向对象语言,这块都帮你处理好了,自然没有关系。######既然有共享空间了,那你所说的进程和线程实际就是一回事了。###### @乌龟壳   ,数据分两种,一种和算法或处理相关的。一种是待处理的数据。 前者,不应该共享,后者属于数据加工流程,必然存在数据传递或流动,最低成本的传递/流动方式就是共享内存,交替使用权限的思路。 但这仅仅针对待加工的数据和辅助信息,而不针对程序本身。 进程不会搞混乱这些东西特别是(待加工数据的辅助信息),而线程,就各种乱吧。哈。 进程之间,虽然用共享空间,但它本质是数据传递/流动,当你采用多机(物理机器)并发处理时,进程移动到另外一个物理主机,则共享空间就是不能选择的传递/流动方式了。但线程就没有这些概念。 ######回复 @中山野鬼 : 是啊,java天然就不是像C一样对汇编的包装。######@乌龟壳 面向企业级的各种业务,java这些没问题的。而且更有优势,面向计算设备特性的设计开发,就不行了。哈。######回复 @中山野鬼 : 也算各有场景吧,java同样可以多进程可以分布式来降低多线程的风险。java也可以静态编译成目标机器码。总之事在人为。######回复 @乌龟壳 : 高手,啥都可以,低手,依赖这些,就是各种想当然。哈哈。######回复 @中山野鬼 : 那针对java的垃圾回收,这个东西是可以调节它算法的,不算依赖工具吧,哈。不然依赖C语言语法也算依赖工具咯。哈。;-p

kun坤 2020-05-31 13:04:51 0 浏览量 回答数 0

问题

电子商务下ERP与CRM的分析

hua2012h 2019-12-01 20:13:28 4707 浏览量 回答数 0

问题

日志采集Agent对比是多少?

轩墨 2019-12-01 22:04:13 1143 浏览量 回答数 0

回答

一、混合加密的理由   a、前面提及了RSA加解密算法和DES加解密算法这两种加解密算法,由于随着计算机系统能力的不断发展,DES的安全性比它刚出现时会弱得多,追溯历史破解DES的案例层出不穷,一台实际的机器可以在数天内破解DES是让某些人相信他们不能依赖DES的安全性的唯一方法。而相对于DES,RSA的安全性则相对高些,虽然破解RSA的案例也有,但其所付出的代价是相对大的(相对DES),如今RSA的密钥也在升级,这说明破解RSA的难度也在增大。   b、在RSA加解密算法中提及到RSA加密明文会受密钥的长度限制,这就说明用RSA加密的话明文长度是有限制的,而在实际情况我们要进行加密的明文长度或许会大于密钥长度,这样一来我们就不得不舍去RSA加密了。对此,DES加密则没有此限制。   鉴于以上两点(个人观点),单独的使用DES或RSA加密可能没有办法满足实际需求,所以就采用了RSA和DES加密方法相结合的方式来实现数据的加密。   其实现方式即:   1、信息(明文)采用DES密钥加密。   2、使用RSA加密前面的DES密钥信息。   最终将混合信息进行传递。   而接收方接收到信息后:   1、用RSA解密DES密钥信息。   2、再用RSA解密获取到的密钥信息解密密文信息。   最终就可以得到我们要的信息(明文)。 二、实现例子: 结合前面RSA和DES加密: /// <summary> /// RSA和DES混合加密 /// </summary> /// <param name="data">待加密数据</param> /// <param name="publicKey">RSA公钥</param> /// <returns></returns> public Param Encrypt(string data, string publicKey) { //加密数据 DESSecurity DES = new DESSecurity(); string DESKey = DES.GenerateKey(); string encryptData = DES.Encrypt(data, DESKey); //加密DESkey RSASecurity RSA = new RSASecurity(); string encryptDESKey = RSA.Encrypt(DESKey, publicKey); Param mixParam = new Param(); mixParam.DESKey = encryptDESKey; mixParam.Data = encryptData; return mixParam; } /// <summary> /// RSA和DES混合解密 /// </summary> /// <param name="data">待解密数据</param> /// <param name="key">带解密的DESKey</param> /// <param name="privateKey">RSA私钥</param> /// <returns></returns> public string Decrypt(string data, string key, string privateKey) { //解密DESKey RSASecurity RSA = new RSASecurity(); string DESKey = RSA.Decrypt(key, privateKey); //解密数据 DESSecurity DES = new DESSecurity(); return DES.Decrypt(data, DESKey);

知与谁同 2019-12-02 01:26:48 0 浏览量 回答数 0

问题

jeesz分布式架构-RestFul服务 :报错

kun坤 2020-06-14 12:19:54 0 浏览量 回答数 1

问题

jeesz分布式架构-RestFul服务 - jeesz报错

montos 2020-06-03 15:44:17 4 浏览量 回答数 1

问题

网络营销培训教企业正确进入网络营销时代

暖人暖心 2019-12-01 21:44:47 3056 浏览量 回答数 0

回答

以前也接触过RSA加密算法,感觉这个东西太神秘了,是数学家的事,和我无关。但是,看了很多关于RSA加密算法原理的资料之后,我发现其实原理并不是我们想象中那么复杂,弄懂之后发现原来就只是这样而已.. 学过算法的朋友都知道,计算机中的算法其实就是数学运算。所以,再讲解RSA加密算法之前,有必要了解一下一些必备的数学知识。我们就从数学知识开始讲解。 必备数学知识 RSA加密算法中,只用到素数、互质数、指数运算、模运算等几个简单的数学知识。所以,我们也需要了解这几个概念即可。 素数 素数又称质数,指在一个大于1的自然数中,除了1和此整数自身外,不能被其他自然数整除的数。这个概念,我们在上初中,甚至小学的时候都学过了,这里就不再过多解释了。 互质数 百度百科上的解释是:公因数只有1的两个数,叫做互质数。;维基百科上的解释是:互质,又称互素。若N个整数的最大公因子是1,则称这N个整数互质。 常见的互质数判断方法主要有以下几种: 两个不同的质数一定是互质数。例如,2与7、13与19。 一个质数,另一个不为它的倍数,这两个数为互质数。例如,3与10、5与 26。 相邻的两个自然数是互质数。如 15与 16。 相邻的两个奇数是互质数。如 49与 51。 较大数是质数的两个数是互质数。如97与88。 小数是质数,大数不是小数的倍数的两个数是互质数。例如 7和 16。 2和任何奇数是互质数。例如2和87。 1不是质数也不是合数,它和任何一个自然数在一起都是互质数。如1和9908。 辗转相除法。 指数运算 指数运算又称乘方计算,计算结果称为幂。nm指将n自乘m次。把nm看作乘方的结果,叫做”n的m次幂”或”n的m次方”。其中,n称为“底数”,m称为“指数”。 模运算 模运算即求余运算。“模”是“Mod”的音译。和模运算紧密相关的一个概念是“同余”。数学上,当两个整数除以同一个正整数,若得相同余数,则二整数同余。 两个整数a,b,若它们除以正整数m所得的余数相等,则称a,b对于模m同余,记作: a ≡ b (mod m);读作:a同余于b模m,或者,a与b关于模m同余。例如:26 ≡ 14 (mod 12)。 RSA加密算法 RSA加密算法简史 RSA是1977年由罗纳德·李维斯特(Ron Rivest)、阿迪·萨莫尔(Adi Shamir)和伦纳德·阿德曼(Leonard Adleman)一起提出的。当时他们三人都在麻省理工学院工作。RSA就是他们三人姓氏开头字母拼在一起组成的。 公钥与密钥的产生 假设Alice想要通过一个不可靠的媒体接收Bob的一条私人讯息。她可以用以下的方式来产生一个公钥和一个私钥: 随意选择两个大的质数p和q,p不等于q,计算N=pq。 根据欧拉函数,求得r = (p-1)(q-1) 选择一个小于 r 的整数 e,求得 e 关于模 r 的模反元素,命名为d。(模反元素存在,当且仅当e与r互质) 将 p 和 q 的记录销毁。 (N,e)是公钥,(N,d)是私钥。Alice将她的公钥(N,e)传给Bob,而将她的私钥(N,d)藏起来。 加密消息 假设Bob想给Alice送一个消息m,他知道Alice产生的N和e。他使用起先与Alice约好的格式将m转换为一个小于N的整数n,比如他可以将每一个字转换为这个字的Unicode码,然后将这些数字连在一起组成一个数字。假如他的信息非常长的话,他可以将这个信息分为几段,然后将每一段转换为n。用下面这个公式他可以将n加密为c: ne ≡ c (mod N) 计算c并不复杂。Bob算出c后就可以将它传递给Alice。 解密消息 Alice得到Bob的消息c后就可以利用她的密钥d来解码。她可以用以下这个公式来将c转换为n: cd ≡ n (mod N) 得到n后,她可以将原来的信息m重新复原。 解码的原理是: cd ≡ n e·d(mod N) 以及ed ≡ 1 (mod p-1)和ed ≡ 1 (mod q-1)。由费马小定理可证明(因为p和q是质数) n e·d ≡ n (mod p)   和  n e·d ≡ n (mod q) 这说明(因为p和q是不同的质数,所以p和q互质) n e·d ≡ n (mod pq) 签名消息 RSA也可以用来为一个消息署名。假如甲想给乙传递一个署名的消息的话,那么她可以为她的消息计算一个散列值(Message digest),然后用她的密钥(private key)加密这个散列值并将这个“署名”加在消息的后面。这个消息只有用她的公钥才能被解密。乙获得这个消息后可以用甲的公钥解密这个散列值,然后将这个数据与他自己为这个消息计算的散列值相比较。假如两者相符的话,那么他就可以知道发信人持有甲的密钥,以及这个消息在传播路径上没有被篡改过。 RSA加密算法的安全性 当p和q是一个大素数的时候,从它们的积pq去分解因子p和q,这是一个公认的数学难题。然而,虽然RSA的安全性依赖于大数的因子分解,但并没有从理论上证明破译RSA的难度与大数分解难度等价。 1994年彼得·秀尔(Peter Shor)证明一台量子计算机可以在多项式时间内进行因数分解。假如量子计算机有朝一日可以成为一种可行的技术的话,那么秀尔的算法可以淘汰RSA和相关的衍生算法。(即依赖于分解大整数困难性的加密算法) 另外,假如N的长度小于或等于256位,那么用一台个人电脑在几个小时内就可以分解它的因子了。1999年,数百台电脑合作分解了一个512位长的N。1997年后开发的系统,用户应使用1024位密钥,证书认证机构应用2048位或以上。 RSA加密算法的缺点 虽然RSA加密算法作为目前最优秀的公钥方案之一,在发表三十多年的时间里,经历了各种攻击的考验,逐渐为人们接受。但是,也不是说RSA没有任何缺点。由于没有从理论上证明破译RSA的难度与大数分解难度的等价性。所以,RSA的重大缺陷是无法从理论上把握它的保密性能如何。在实践上,RSA也有一些缺点: 产生密钥很麻烦,受到素数产生技术的限制,因而难以做到一次一密; 分组长度太大,为保证安全性,n 至少也要 600 bits 以上,使运算代价很高,尤其是速度较慢,

沉默术士 2019-12-02 01:26:53 0 浏览量 回答数 0

回答

以前也接触过RSA加密算法,感觉这个东西太神秘了,是数学家的事,和我无关。但是,看了很多关于RSA加密算法原理的资料之后,我发现其实原理并不是我们想象中那么复杂,弄懂之后发现原来就只是这样而已..   学过算法的朋友都知道,计算机中的算法其实就是数学运算。所以,再讲解RSA加密算法之前,有必要了解一下一些必备的数学知识。我们就从数学知识开始讲解。 必备数学知识   RSA加密算法中,只用到素数、互质数、指数运算、模运算等几个简单的数学知识。所以,我们也需要了解这几个概念即可。 素数   素数又称质数,指在一个大于1的自然数中,除了1和此整数自身外,不能被其他自然数整除的数。这个概念,我们在上初中,甚至小学的时候都学过了,这里就不再过多解释了。 互质数   百度百科上的解释是:公因数只有1的两个数,叫做互质数。;维基百科上的解释是:互质,又称互素。若N个整数的最大公因子是1,则称这N个整数互质。   常见的互质数判断方法主要有以下几种: 两个不同的质数一定是互质数。例如,2与7、13与19。 一个质数,另一个不为它的倍数,这两个数为互质数。例如,3与10、5与 26。 相邻的两个自然数是互质数。如 15与 16。 相邻的两个奇数是互质数。如 49与 51。 较大数是质数的两个数是互质数。如97与88。 小数是质数,大数不是小数的倍数的两个数是互质数。例如 7和 16。 2和任何奇数是互质数。例如2和87。 1不是质数也不是合数,它和任何一个自然数在一起都是互质数。如1和9908。 辗转相除法。 指数运算   指数运算又称乘方计算,计算结果称为幂。nm指将n自乘m次。把nm看作乘方的结果,叫做”n的m次幂”或”n的m次方”。其中,n称为“底数”,m称为“指数”。 模运算   模运算即求余运算。“模”是“Mod”的音译。和模运算紧密相关的一个概念是“同余”。数学上,当两个整数除以同一个正整数,若得相同余数,则二整数同余。   两个整数a,b,若它们除以正整数m所得的余数相等,则称a,b对于模m同余,记作: a ≡ b (mod m);读作:a同余于b模m,或者,a与b关于模m同余。例如:26 ≡ 14 (mod 12)。 RSA加密算法 RSA加密算法简史   RSA是1977年由罗纳德·李维斯特(Ron Rivest)、阿迪·萨莫尔(Adi Shamir)和伦纳德·阿德曼(Leonard Adleman)一起提出的。当时他们三人都在麻省理工学院工作。RSA就是他们三人姓氏开头字母拼在一起组成的。 公钥与密钥的产生   假设Alice想要通过一个不可靠的媒体接收Bob的一条私人讯息。她可以用以下的方式来产生一个公钥和一个私钥: 随意选择两个大的质数p和q,p不等于q,计算N=pq。 根据欧拉函数,求得r = (p-1)(q-1) 选择一个小于 r 的整数 e,求得 e 关于模 r 的模反元素,命名为d。(模反元素存在,当且仅当e与r互质) 将 p 和 q 的记录销毁。 (N,e)是公钥,(N,d)是私钥。Alice将她的公钥(N,e)传给Bob,而将她的私钥(N,d)藏起来。 加密消息   假设Bob想给Alice送一个消息m,他知道Alice产生的N和e。他使用起先与Alice约好的格式将m转换为一个小于N的整数n,比如他可以将每一个字转换为这个字的Unicode码,然后将这些数字连在一起组成一个数字。假如他的信息非常长的话,他可以将这个信息分为几段,然后将每一段转换为n。用下面这个公式他可以将n加密为c:   ne ≡ c (mod N) 计算c并不复杂。Bob算出c后就可以将它传递给Alice。 解密消息 Alice得到Bob的消息c后就可以利用她的密钥d来解码。她可以用以下这个公式来将c转换为n:   cd ≡ n (mod N) 得到n后,她可以将原来的信息m重新复原。 解码的原理是:   cd ≡ n e·d(mod N) 以及ed ≡ 1 (mod p-1)和ed ≡ 1 (mod q-1)。由费马小定理可证明(因为p和q是质数)   n e·d ≡ n (mod p)   和  n e·d ≡ n (mod q) 这说明(因为p和q是不同的质数,所以p和q互质)   n e·d ≡ n (mod pq) 签名消息   RSA也可以用来为一个消息署名。假如甲想给乙传递一个署名的消息的话,那么她可以为她的消息计算一个散列值(Message digest),然后用她的密钥(private key)加密这个散列值并将这个“署名”加在消息的后面。这个消息只有用她的公钥才能被解密。乙获得这个消息后可以用甲的公钥解密这个散列值,然后将这个数据与他自己为这个消息计算的散列值相比较。假如两者相符的话,那么他就可以知道发信人持有甲的密钥,以及这个消息在传播路径上没有被篡改过。 RSA加密算法的安全性   当p和q是一个大素数的时候,从它们的积pq去分解因子p和q,这是一个公认的数学难题。然而,虽然RSA的安全性依赖于大数的因子分解,但并没有从理论上证明破译RSA的难度与大数分解难度等价。   1994年彼得·秀尔(Peter Shor)证明一台量子计算机可以在多项式时间内进行因数分解。假如量子计算机有朝一日可以成为一种可行的技术的话,那么秀尔的算法可以淘汰RSA和相关的衍生算法。(即依赖于分解大整数困难性的加密算法)   另外,假如N的长度小于或等于256位,那么用一台个人电脑在几个小时内就可以分解它的因子了。1999年,数百台电脑合作分解了一个512位长的N。1997年后开发的系统,用户应使用1024位密钥,证书认证机构应用2048位或以上。 RSA加密算法的缺点   虽然RSA加密算法作为目前最优秀的公钥方案之一,在发表三十多年的时间里,经历了各种攻击的考验,逐渐为人们接受。但是,也不是说RSA没有任何缺点。由于没有从理论上证明破译RSA的难度与大数分解难度的等价性。所以,RSA的重大缺陷是无法从理论上把握它的保密性能如何。在实践上,RSA也有一些缺点: 产生密钥很麻烦,受到素数产生技术的限制,因而难以做到一次一密; 分组长度太大,为保证安全性,n 至少也要 600 bits 以上,使运算代价很高,尤其是速度较慢,。

小旋风柴进 2019-12-02 01:27:11 0 浏览量 回答数 0

回答

密码知识 谈起密码算法,有的人会觉得陌生,但一提起PGP,大多数网上朋友都很熟悉,它是一个工具软件,向认证中心注册后就可以用它对文件进行加解密或数字签名,PGP所采用的是RSA算法,以后我们会对它展开讨论。密码算法的目的是为了保护信息的保密性、完整性和安全性,简单地说就是信息的防伪造与防窃取,这一点在网上付费系统中特别有意义。密码学的鼻祖可以说是信息论的创始人香农,他提出了一些概念和基本理论,论证了只有一种密码算法是理论上不可解的,那就是 One Time Padding,这种算法要求采用一个随机的二进制序列作为密钥,与待加密的二进制序列按位异或,其中密钥的长度不小于待加密的二进制序列的长度,而且一个密钥只能使用一次。其它算法都是理论上可解的。如DES算法,其密钥实际长度是56比特,作2^56次穷举,就肯定能找到加密使用的密钥。所以采用的密码算法做到事实上不可解就可以了,当一个密码算法已知的破解算法的时间复杂度是指数级时,称该算法为事实上不可解的。顺便说一下,据报道国外有人只用七个半小时成功破解了DES算法。密码学在不断发展变化之中,因为人类的计算能力也像摩尔定律提到的一样飞速发展。作为第一部分,首先谈一下密码算法的概念。 密码算法可以看作是一个复杂的函数变换,C = F M, Key ),C代表密文,即加密后得到的字符序列,M代表明文即待加密的字符序列,Key表示密钥,是秘密选定的一个字符序列。密码学的一个原则是“一切秘密寓于密钥之中”,算法可以公开。当加密完成后,可以将密文通过不安全渠道送给收信人,只有拥有解密密钥的收信人可以对密文进行解密即反变换得到明文,密钥的传递必须通过安全渠道。目前流行的密码算法主要有DESRSA,IDEA,DSA等,还有新近的Liu氏算法,是由华人刘尊全发明的。密码算法可分为传统密码算法和现代密码算法,传统密码算法的特点是加密和解密必须是同一密钥,如DES和IDEA等;现代密码算法将加密密钥与解密密钥区分开来,且由加密密钥事实上求不出解密密钥。这样一个实体只需公开其加密密钥(称公钥,解密密钥称私钥)即可,实体之间就可以进行秘密通信,而不象传统密码算法似的在通信之前先得秘密传递密钥,其中妙处一想便知。因此传统密码算法又称对称密码算法(Symmetric Cryptographic Algorithms ),现代密码算法称非对称密码算法或公钥密码算法( Public-Key Cryptographic Algorithms ),是由Diffie 和Hellman首先在1976年的美国国家计算机会议上提出这一概念的。按照加密时对明文的处理方式,密码算法又可分为分组密码算法和序列密码算法。分组密码算法是把密文分成等长的组分别加密,序列密码算法是一个比特一个比特地处理,用已知的密钥随机序列与明文按位异或。当然当分组长度为1时,二者混为一谈。这些算法以后我们都会具体讨论。 RSA算法 1978年就出现了这种算法,它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作,也很流行。算法的名字以发明者的名字命名:Ron Rivest, AdiShamir 和Leonard Adleman。但RSA的安全性一直未能得到理论上的证明。 RSA的安全性依赖于大数分解。公钥和私钥都是两个大素数( 大于 100个十进制位)的函数。据猜测,从一个密钥和密文推断出明文的难度等同于分解两个大素数的积。 密钥对的产生。选择两个大素数,p 和q 。计算: n = p * q 然后随机选择加密密钥e,要求 e 和 ( p - 1 ) * ( q - 1 ) 互质。最后,利用Euclid 算法计算解密密钥d, 满足 e * d = 1 ( mod ( p - 1 ) * ( q - 1 ) ) 其中n和d也要互质。数e和n是公钥,d是私钥。两个素数p和q不再需要,应该丢弃,不要让任何人知道。 加密信息 m(二进制表示)时,首先把m分成等长数据块 m1 ,m2,..., mi ,块长s,其中 2^s <= n, s 尽可能的大。对应的密文是: ci = mi^e ( mod n ) ( a ) 解密时作如下计算: mi = ci^d ( mod n ) ( b ) RSA 可用于数字签名,方案是用 ( a ) 式签名, ( b )式验证。具体操作时考虑到安全性和 m信息量较大等因素,一般是先作 HASH 运算。 RSA 的安全性。 RSA的安全性依赖于大数分解,但是否等同于大数分解一直未能得到理论上的证明,因为没有证明破解 RSA就一定需要作大数分解。假设存在一种无须分解大数的算法,那它肯定可以修改成为大数分解算法。目前, RSA的一些变种算法已被证明等价于大数分解。不管怎样,分解n是最显然的攻击方法。现在,人们已能分解140多个十进制位的大素数。因此,模数n必须选大一些,因具体适用情况而定。 RSA的速度。 由于进行的都是大数计算,使得RSA最快的情况也比DES慢上100倍,无论是软件还是硬件实现。速度一直是RSA的缺陷。一般来说只用于少量数据加密。 RSA的选择密文攻击。 RSA在选择密文攻击面前很脆弱。一般攻击者是将某一信息作一下伪装(Blind),让拥有私钥的实体签署。然后,经过计算就可得到它所想要的信息。实际上,攻击利用的都是同一个弱点,即存在这样一个事实:乘幂保留了输入的乘法结构: ( XM )^d = X^d *M^d mod n 前面已经提到,这个固有的问题来自于公钥密码系统的最有用的特征--每个人都能使用公钥。但从算法上无法解决这一问题,主要措施有两条:一条是采用好的公钥协议,保证工作过程中实体不对其他实体任意产生的信息解密,不对自己一无所知的信息签名;另一条是决不对陌生人送来的随机文档签名,签名时首先使用One-Way Hash Function对文档作HASH处理,或同时使用不同的签名算法。在中提到了几种不同类型的攻击方法。 RSA的公共模数攻击。 若系统中共有一个模数,只是不同的人拥有不同的e和d,系统将是危险的。最普遍的情况是同一信息用不同的公钥加密,这些公钥共模而且互质,那末该信息无需私钥就可得到恢复。设P为信息明文,两个加密密钥为e1和e2,公共模数是n,则: C1 = P^e1 mod n C2 = P^e2 mod n 密码分析者知道n、e1、e2、C1和C2,就能得到P。 因为e1和e2互质,故用Euclidean算法能找到r和s,满足: r * e1 + s * e2 = 1 假设r为负数,需再用Euclidean算法计算C1^(-1),则 ( C1^(-1) )^(-r) * C2^s = P mod n 另外,还有其它几种利用公共模数攻击的方法。总之,如果知道给定模数的一对e和d,一是有利于攻击者分解模数,一是有利于攻击者计算出其它成对的e’和d’,而无需分解模数。解决办法只有一个,那就是不要共享模数n。 RSA的小指数攻击。 有一种提高RSA速度的建议是使公钥e取较小的值,这样会使加密变得易于实现,速度有所提高。但这样作是不安全的,对付办法就是e和d都取较大的值。 RSA算法是第一个能同时用于加密和数字签名的算法,也易于理解和操作。RSA是被研究得最广泛的公钥算法,从提出到现在已近二十年,经历了各种攻击的考验,逐渐为人们接受,普遍认为是目前最优秀的公钥方案之一。RSA的安全性依赖于大数的因子分解,但并没有从理论上证明破译RSA的难度与大数分解难度等价。即RSA的重大缺陷是无法从理论上把握它的保密性能如何,而且密码学界多数人士倾向于因子分解不是NPC问题。 RSA的缺点主要有:A)产生密钥很麻烦,受到素数产生技术的限制,因而难以做到一次一密。B)分组长度太大,为保证安全性,n 至少也要 600 bits以上,使运算代价很高,尤其是速度较慢,较对称密码算法慢几个数量级;且随着大数分解技术的发展,这个长度还在增加,不利于数据格式的标准化。目前,SET(Secure Electronic Transaction)协议中要求CA采用2048比特长的密钥,其他实体使用1024比特的密钥。 DSS/DSA算法 Digital Signature Algorithm (DSA)是Schnorr和ElGamal签名算法的变种,被美国NIST作为DSS(Digital SignatureStandard)。算法中应用了下述参数: p:L bits长的素数。L是64的倍数,范围是512到1024; q:p - 1的160bits的素因子; g:g = h^((p-1)/q) mod p,h满足h < p - 1, h^((p-1)/q) mod p > 1; x:x < q,x为私钥 ; y:y = g^x mod p ,( p, q, g, y )为公钥; H( x ):One-Way Hash函数。DSS中选用SHA( Secure Hash Algorithm )。 p, q, g可由一组用户共享,但在实际应用中,使用公共模数可能会带来一定的威胁。签名及验证协议如下: 1. P产生随机数k,k < q; 2. P计算 r = ( g^k mod p ) mod q s = ( k^(-1) (H(m) + xr)) mod q 签名结果是( m, r, s )。 3. 验证时计算 w = s^(-1)mod q u1 = ( H( m ) * w ) mod q u2 = ( r * w ) mod q v = (( g^u1 * y^u2 ) mod p ) mod q 若v = r,则认为签名有效。 DSA是基于整数有限域离散对数难题的,其安全性与RSA相比差不多。DSA的一个重要特点是两个素数公开,这样,当使用别人的p和q时,即使不知道私钥,你也能确认它们是否是随机产生的,还是作了手脚。RSA算法却作不到。

沉默术士 2019-12-02 01:27:01 0 浏览量 回答数 0

回答

密码知识 谈起密码算法,有的人会觉得陌生,但一提起PGP,大多数网上朋友都很熟悉,它是一个工具软件,向认证中心注册后就可以用它对文件进行加解密或数字签名,PGP所采用的是RSA算法,以后我们会对它展开讨论。密码算法的目的是为了保护信息的保密性、完整性和安全性,简单地说就是信息的防伪造与防窃取,这一点在网上付费系统中特别有意义。密码学的鼻祖可以说是信息论的创始人香农,他提出了一些概念和基本理论,论证了只有一种密码算法是理论上不可解的,那就是 One Time Padding,这种算法要求采用一个随机的二进制序列作为密钥,与待加密的二进制序列按位异或,其中密钥的长度不小于待加密的二进制序列的长度,而且一个密钥只能使用一次。其它算法都是理论上可解的。如DES算法,其密钥实际长度是56比特,作2^56次穷举,就肯定能找到加密使用的密钥。所以采用的密码算法做到事实上不可解就可以了,当一个密码算法已知的破解算法的时间复杂度是指数级时,称该算法为事实上不可解的。顺便说一下,据报道国外有人只用七个半小时成功破解了DES算法。密码学在不断发展变化之中,因为人类的计算能力也像摩尔定律提到的一样飞速发展。作为第一部分,首先谈一下密码算法的概念。 密码算法可以看作是一个复杂的函数变换,C = F M, Key ),C代表密文,即加密后得到的字符序列,M代表明文即待加密的字符序列,Key表示密钥,是秘密选定的一个字符序列。密码学的一个原则是“一切秘密寓于密钥之中”,算法可以公开。当加密完成后,可以将密文通过不安全渠道送给收信人,只有拥有解密密钥的收信人可以对密文进行解密即反变换得到明文,密钥的传递必须通过安全渠道。目前流行的密码算法主要有DESRSA,IDEA,DSA等,还有新近的Liu氏算法,是由华人刘尊全发明的。密码算法可分为传统密码算法和现代密码算法,传统密码算法的特点是加密和解密必须是同一密钥,如DES和IDEA等;现代密码算法将加密密钥与解密密钥区分开来,且由加密密钥事实上求不出解密密钥。这样一个实体只需公开其加密密钥(称公钥,解密密钥称私钥)即可,实体之间就可以进行秘密通信,而不象传统密码算法似的在通信之前先得秘密传递密钥,其中妙处一想便知。因此传统密码算法又称对称密码算法(Symmetric Cryptographic Algorithms ),现代密码算法称非对称密码算法或公钥密码算法( Public-Key Cryptographic Algorithms ),是由Diffie 和Hellman首先在1976年的美国国家计算机会议上提出这一概念的。按照加密时对明文的处理方式,密码算法又可分为分组密码算法和序列密码算法。分组密码算法是把密文分成等长的组分别加密,序列密码算法是一个比特一个比特地处理,用已知的密钥随机序列与明文按位异或。当然当分组长度为1时,二者混为一谈。这些算法以后我们都会具体讨论。 RSA算法 1978年就出现了这种算法,它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作,也很流行。算法的名字以发明者的名字命名:Ron Rivest, AdiShamir 和Leonard Adleman。但RSA的安全性一直未能得到理论上的证明。 RSA的安全性依赖于大数分解。公钥和私钥都是两个大素数( 大于 100个十进制位)的函数。据猜测,从一个密钥和密文推断出明文的难度等同于分解两个大素数的积。 密钥对的产生。选择两个大素数,p 和q 。计算: n = p * q 然后随机选择加密密钥e,要求 e 和 ( p - 1 ) * ( q - 1 ) 互质。最后,利用Euclid 算法计算解密密钥d, 满足 e * d = 1 ( mod ( p - 1 ) * ( q - 1 ) ) 其中n和d也要互质。数e和n是公钥,d是私钥。两个素数p和q不再需要,应该丢弃,不要让任何人知道。 加密信息 m(二进制表示)时,首先把m分成等长数据块 m1 ,m2,..., mi ,块长s,其中 2^s <= n, s 尽可能的大。对应的密文是: ci = mi^e ( mod n ) ( a ) 解密时作如下计算: mi = ci^d ( mod n ) ( b ) RSA 可用于数字签名,方案是用 ( a ) 式签名, ( b )式验证。具体操作时考虑到安全性和 m信息量较大等因素,一般是先作 HASH 运算。 RSA 的安全性。 RSA的安全性依赖于大数分解,但是否等同于大数分解一直未能得到理论上的证明,因为没有证明破解 RSA就一定需要作大数分解。假设存在一种无须分解大数的算法,那它肯定可以修改成为大数分解算法。目前, RSA的一些变种算法已被证明等价于大数分解。不管怎样,分解n是最显然的攻击方法。现在,人们已能分解140多个十进制位的大素数。因此,模数n必须选大一些,因具体适用情况而定。 RSA的速度。 由于进行的都是大数计算,使得RSA最快的情况也比DES慢上100倍,无论是软件还是硬件实现。速度一直是RSA的缺陷。一般来说只用于少量数据加密。 RSA的选择密文攻击。 RSA在选择密文攻击面前很脆弱。一般攻击者是将某一信息作一下伪装(Blind),让拥有私钥的实体签署。然后,经过计算就可得到它所想要的信息。实际上,攻击利用的都是同一个弱点,即存在这样一个事实:乘幂保留了输入的乘法结构: ( XM )^d = X^d *M^d mod n 前面已经提到,这个固有的问题来自于公钥密码系统的最有用的特征--每个人都能使用公钥。但从算法上无法解决这一问题,主要措施有两条:一条是采用好的公钥协议,保证工作过程中实体不对其他实体任意产生的信息解密,不对自己一无所知的信息签名;另一条是决不对陌生人送来的随机文档签名,签名时首先使用One-Way Hash Function对文档作HASH处理,或同时使用不同的签名算法。在中提到了几种不同类型的攻击方法。 RSA的公共模数攻击。 若系统中共有一个模数,只是不同的人拥有不同的e和d,系统将是危险的。最普遍的情况是同一信息用不同的公钥加密,这些公钥共模而且互质,那末该信息无需私钥就可得到恢复。设P为信息明文,两个加密密钥为e1和e2,公共模数是n,则: C1 = P^e1 mod n C2 = P^e2 mod n 密码分析者知道n、e1、e2、C1和C2,就能得到P。 因为e1和e2互质,故用Euclidean算法能找到r和s,满足: r * e1 + s * e2 = 1 假设r为负数,需再用Euclidean算法计算C1^(-1),则 ( C1^(-1) )^(-r) * C2^s = P mod n 另外,还有其它几种利用公共模数攻击的方法。总之,如果知道给定模数的一对e和d,一是有利于攻击者分解模数,一是有利于攻击者计算出其它成对的e’和d’,而无需分解模数。解决办法只有一个,那就是不要共享模数n。 RSA的小指数攻击。 有一种提高RSA速度的建议是使公钥e取较小的值,这样会使加密变得易于实现,速度有所提高。但这样作是不安全的,对付办法就是e和d都取较大的值。 RSA算法是第一个能同时用于加密和数字签名的算法,也易于理解和操作。RSA是被研究得最广泛的公钥算法,从提出到现在已近二十年,经历了各种攻击的考验,逐渐为人们接受,普遍认为是目前最优秀的公钥方案之一。RSA的安全性依赖于大数的因子分解,但并没有从理论上证明破译RSA的难度与大数分解难度等价。即RSA的重大缺陷是无法从理论上把握它的保密性能如何,而且密码学界多数人士倾向于因子分解不是NPC问题。 RSA的缺点主要有:A)产生密钥很麻烦,受到素数产生技术的限制,因而难以做到一次一密。B)分组长度太大,为保证安全性,n 至少也要 600 bits以上,使运算代价很高,尤其是速度较慢,较对称密码算法慢几个数量级;且随着大数分解技术的发展,这个长度还在增加,不利于数据格式的标准化。目前,SET(Secure Electronic Transaction)协议中要求CA采用2048比特长的密钥,其他实体使用1024比特的密钥。 DSS/DSA算法 Digital Signature Algorithm (DSA)是Schnorr和ElGamal签名算法的变种,被美国NIST作为DSS(Digital SignatureStandard)。算法中应用了下述参数: p:L bits长的素数。L是64的倍数,范围是512到1024; q:p - 1的160bits的素因子; g:g = h^((p-1)/q) mod p,h满足h < p - 1, h^((p-1)/q) mod p > 1; x:x < q,x为私钥 ; y:y = g^x mod p ,( p, q, g, y )为公钥; H( x ):One-Way Hash函数。DSS中选用SHA( Secure Hash Algorithm )。 p, q, g可由一组用户共享,但在实际应用中,使用公共模数可能会带来一定的威胁。签名及验证协议如下: 1. P产生随机数k,k < q; 2. P计算 r = ( g^k mod p ) mod q s = ( k^(-1) (H(m) + xr)) mod q 签名结果是( m, r, s )。 3. 验证时计算 w = s^(-1)mod q u1 = ( H( m ) * w ) mod q u2 = ( r * w ) mod q v = (( g^u1 * y^u2 ) mod p ) mod q 若v = r,则认为签名有效。 DSA是基于整数有限域离散对数难题的,其安全性与RSA相比差不多。DSA的一个重要特点是两个素数公开,这样,当使用别人的p和q时,即使不知道私钥,你也能确认它们是否是随机产生的,还是作了手脚。RSA算法却作不到。

行者武松 2019-12-02 01:27:12 0 浏览量 回答数 0

回答

你看项目中用到的就行了,跟着写  ######PO(Persistant Object) 持久对象 用于表示数据库中的一条记录映射成的 java 对象。PO 仅仅用于表示数据,没有任何数据操作。通常遵守 Java Bean 的规范,拥有 getter/setter 方法。 可以理解是一个PO就是数据库中的一条记录;可以理解某个事务依赖的原始数据;好处是可以将一条记录最为一个对象处理,可以方便转化为其他对象 BO(Business Object) 业务对象 封装对象、复杂对象,里面可能包含多个类 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。 用于表示一个业务对象。BO 包括了业务逻辑,常常封装了对 DAO、RPC 等的调用,可以进行 PO 与 VO/DTO 之间的转换。BO 通常位于业务层,要区别于直接对外提供服务的服务层:BO 提供了基本业务单元的基本业务操作,在设计上属于被服务层业务流程调用的对象,一个业务流程可能需要调用多个 BO 来完成。 比如一个简历,有教育经历、工作经历、社会关系等等。 我们可以把教育经历对应一个PO,工作经历对应一个PO,社会关系对应一个PO。 建立一个对应简历的BO对象处理简历,每个BO包含这些PO。 这样处理业务逻辑时,我们就可以针对BO去处理。 VO(Value Object) 表现对象 前端界面展示;value object值对象;ViewObject表现层对象;主要对应界面显示的数据对象。对于一个WEB页面,或者SWT、SWING的一个界面,用一个VO对象对应整个界面的值;对于Android而言即是activity或view中的数据元素。 用于表示一个与前端进行交互的 java 对象。有的朋友也许有疑问,这里可不可以使用 PO 传递数据?实际上,这里的 VO 只包含前端需要展示的数据即可,对于前端不需要的数据,比如数据创建和修改的时间等字段,出于减少传输数据量大小和保护数据库结构不外泄的目的,不应该在 VO 中体现出来。通常遵守 Java Bean 的规范,拥有 getter/setter 方法。 DTO(Data Transfer Object) 数据传输对象 前端调用时传输;也可理解成“上层”调用时传输; 比如我们一张表有100个字段,那么对应的PO就有100个属性。但是我们界面上只要显示10个字段,客户端用WEB service来获取数据,没有必要把整个PO对象传递到客户端,这时我们就可以用只有这10个属性的DTO来传递结果到客户端,这样也不会暴露服务端表结构.到达客户端以后,如果用这个对象来对应界面显示,那此时它的身份就转为VO. 用于表示一个数据传输对象。DTO 通常用于不同服务或服务不同分层之间的数据传输。DTO 与 VO 概念相似,并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同,这个不同主要是设计理念上的,比如 API 服务需要使用的 DTO 就可能与 VO 存在差异。通常遵守 Java Bean 的规范,拥有 getter/setter 方法 DAO(Data access object) 数据访问对象 这个大家最熟悉,和上面几个O区别最大,基本没有互相转化的可能性和必要.,主要用来封装对数据库的访问。通过它可以把POJO持久化为PO,用PO组装出来VO、DTO; 用于表示一个数据访问对象。使用 DAO 访问数据库,包括插入、更新、删除、查询等操作,与 PO 一起使用。DAO 一般在持久层,完全封装数据库操作,对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。 POJO(Plain ordinary java object) 简单java对象  

kun坤 2020-06-09 11:08:56 0 浏览量 回答数 0

回答

为什么你的代码是一个单体? 除了已经实现了微前端的应用之外,所有前端应用本质上都是单一的应用。原因是如果您正在使用 React 库进行开发,并且如果您有两个团队,则两个团队都应该使用相同的React 库,并且两个团队应该在部署时保持同步,并且在代码合并期间始终会发生冲突。它们没有完全分离,很可能它们维护着相同的仓库并具有相同的构建系统。单体应用的退出被标志为微服务的出现。但是它适用于后端! 什么是微服务? 对于微服务,一般而言最简单的解释是,它是一种开发技术,允许开发人员为平台的不同部分进行独立部署,而不会损害其他部分。独立部署的能力允许他们构建孤立或松散耦合的服务。为了使这个体系结构更稳定,有一些规则要遵循,可以总结如下:每个服务应该只有一个任务,它应该很小。所以负责这项服务的团队应该很小。关于团队和项目的规模,James Lewis 和 Martin Fowler 在互联网上做出的最酷解释之一如下: 在我们与微服务从业者的对话中,我们看到了一系列服务规模。报道的最大规模遵循亚马逊关于Two Pizza Team的概念(即整个团队可以由两个比萨饼供给),意味着不超过十几个人。在规模较小的规模上,我们已经看到了一个由六人组成的团队支持六项服务的设置。 我画了一个简单的草图,为整体和微服务提供了直观的解释: 从上图可以理解,微服务中的每个服务都是一个独立的应用,除了UI。UI仍然是一体的!当一个团队处理所有服务并且公司正在扩展时,前端团队将开始苦苦挣扎并且无法跟上它,这是这种架构的瓶颈。 除了瓶颈之外,这种架构也会导致一些组织问题。假设公司正在发展并将采用需要 跨职能 小团队的敏捷开发方法。在这个常见的例子中,产品所有者自然会开始将故事定义为前端和后端任务,而 跨职能 团队将永远不会成为真正的 跨职能 部门。这将是一个浅薄的泡沫,看起来像一个敏捷的团队,但它将在内部分开。关于管理这种团队的更多信息将是一项非常重要的工作。在每个计划中,如果有足够的前端任务或者sprint中有足够的后端任务,则会有一个问题。为了解决这里描述的所有问题和许多其他问题,几年前出现了微前端的想法并且开始迅速普及。 解决微服务中的瓶颈问题:Micro Frontends 解决方案实际上非常明显,采用了多年来为后端服务工作的相同原则:将前端整体划分为小的UI片段。但UI与服务并不十分相似,它是最终用户与产品之间的接口,应该是一致且无缝的。更重要的是,在单页面应用时代,整个应用在客户端的浏览器上运行。它们不再是简单的HTML文件,相反,它们是复杂的软件,达到了非常复杂的水平。现在我觉得微型前端的定义是必要的: Micro Frontends背后的想法是将网站或Web应用视为独立团队拥有的功能组合。每个团队都有一个独特的业务或任务领域,做他们关注和专注的事情。团队是跨职能的,从数据库到用户界面开发端到端的功能。(micro-frontends.org) 根据我迄今为止的经验,对于许多公司来说,直接采用上面提出的架构真的很难。许多其他人都有巨大的遗留负担,这使他们无法迁移到新的架构。出于这个原因,更柔软的中间解决方案更加灵活,易于采用和安全迁移至关重要。在更详细地概述了体系结构后,我将尝试提供一些体系结构的洞察,该体系结构确认了上述提议并允许更灵活的方式。在深入了解细节之前,我需要建立一些术语。 整体结构和一些术语 让我们假设我们通过业务功能垂直划分整体应用结构。我们最终会得到几个较小的应用,它们与单体应用具有相同的结构。但是如果我们在所有这些小型单体应用之上添加一个特殊应用,用户将与这个新应用进行通信,它将把每个小应用的旧单体UI组合成一个。这个新图层可以命名为拼接图层,因为它从每个微服务中获取生成的UI部件,并为最终用户组合成一个无缝 UI,这将是微前端的最直接实现朗 为了更好地理解,我将每个小型单体应用称为微应用,因为它们都是独立的应用,而不仅仅是微服务,它们都有UI部件,每个都代表端到端的业务功能。 众所周知,今天的前端生态系统功能多样,而且非常复杂。因此,当实现真正的产品时,这种直接的解决方案还不够。 要解决的问题 虽然这篇文章只是一个想法,但我开始使用Reddit讨论这个想法。感谢社区和他们的回复,我可以列出一些需要解决的问题,我将尝试逐一描述。 当我们拥有一个完全独立的独立微应用时,如何创建无缝且一致的UI体验? 好吧,这个问题没有灵丹妙药的答案,但其中一个想法是创建一个共享的UI库,它也是一个独立的微应用。通过这种方式,所有其他微应用将依赖于共享的UI库微应用。在这种情况下,我们刚刚创建了一个共享依赖项, 我们就杀死了独立微应用的想法。 另一个想法是在根级共享CSS自定义变量( CSS custom variables )。此解决方案的优势在于应用之间的全局可配置主题。 或者我们可以简单地在应用团队之间共享一些SASS变量和混合。这种方法的缺点是UI元素的重复实现,并且应该对所有微应用始终检查和验证类似元素的设计的完整性。 我们如何确保一个团队不会覆盖另一个团队编写的CSS? 一种解决方案是通过CSS选择器名称进行CSS定义,这些名称由微应用名称精心选择。通过将该范围任务放在拼接层上将减少开发开销,但会增加拼接层的责任。 另一种解决方案可以是强制每个微应用成为自定义Web组件(custom web component)。这个解决方案的优点是浏览器完成了范围设计,但需要付出代价:使用shadow DOM进行服务器端渲染几乎是不可能的。此外,自定义元素没有100%的浏览器支持,特别是IE。 我们应该如何在微应用之间共享全局信息? 这个问题指出了关于这个主题的最关注的问题之一,但解决方案非常简单:HTML 5具有相当强大的功能,大多数前端开发人员都不知道。例如,自定义事件(custom events) 就是其中之一,它是在微应用中共享信息的解决方案。 或者,任何共享的pub-sub实现或T39可观察的实现都可以实现。如果我们想要一个更复杂的全局状态处理程序,我们可以实现共享的微型Redux,通过这种方式我们可以实现更多的相应式架构。 如果所有微应用都是独立应用,我们如何进行客户端路由? 这个问题取决于设计的每个实现, 所有主要的现代框架都通过使用浏览器历史状态在客户端提供强大的路由机制, 问题在于哪个应用负责路由以及何时。 我目前的实用方法是创建一个共享客户端路由器,它只负责顶级路由,其余路由器属于相应的微应用。假设我们有 /content/:id 路由定义。共享路由器将解析 /content,已解析的路由将传递到ContentMicroApp。ContentMicroApp是一个独立的服务器,它将仅使用 /:id 进行调用。 我们必须是服务器端渲染,但是有可能使用微前端吗? 服务器端呈现是一个棘手的问题。如果你正在考虑iframes缝合微应用然后忘记服务器端渲染。同样,拼接任务的Web组件也不比iframe强大。但是,如果每个微应用能够在服务器端呈现其内容,那么拼接层将仅负责连接服务器端的HTML片段。 与传统环境集成至关重要!但是怎么样? 为了整合遗留系统,我想描述我自己的策略,我称之为“ 渐进式入侵 ”。 首先,我们必须实现拼接层,它应该具有透明代理的功能。然后我们可以通过声明一个通配符路径将遗留系统定义为微应用:LegacyMicroApp 。因此,所有流量都将到达拼接层,并将透明地代理到旧系统,因为我们还没有任何其他微应用。 下一步将是我们的 第一次逐步入侵 :我们将从LegacyMicroApp中删除主要导航并用依赖项替换它。这种依赖关系将是一个使用闪亮的新技术实现的微应用:NavigationMicroApp 。 现在,拼接层将每个路径解析为 Legacy Micro App ,它将依赖关系解析为 Navigation MicroApp ,并通过连接这两个来为它们提供服务。 然后通过主导航遵循相同的模式来为引导下一步。 然后我们将继续从Legacy MicroApp中获取逐步重复以上操作,直到没有任何遗漏。 如何编排客户端,这样我们每次都不需要重新加载页面? 拼接层解决了服务器端的问题,但没有解决客户端问题。在客户端,在将已粘贴的片段作为无缝HTML加载后,我们不需要每次在URL更改时加载所有部分。因此,我们必须有一些异步加载片段的机制。但问题是,这些片段可能有一些依赖关系,这些依赖关系需要在客户端解决。这意味着微前端解决方案应提供加载微应用的机制,以及依赖注入的一些机制。 根据上述问题和可能的解决方案,我可以总结以下主题下的所有内容: 客户端 编排路由隔离微应用应用之间通信微应用UI之间的一致性 服务端 服务端渲染路由依赖管理 灵活、强大而简单的架构 所以,这篇文章还是很值得期待的!微前端架构的基本要素和要求终于显现! 在这些要求和关注的指导下,我开始开发一种名为microfe的解决方案。在这里,我将通过抽象的方式强调其主要组件来描述该项目的架构目标。 它很容易从客户端开始,它有三个独立的主干结构:AppsManager, Loader, Router 和一个额外的MicroAppStore。 AppsManager AppsManager 是客户端微应用编排的核心。AppsManager的主要功能是创建依赖关系树。当解决了微应用的所有依赖关系时,它会实例化微应用。 Loader 客户端微应用编排的另一个重要部分是Loader。加载器的责任是从服务器端获取未解析的微应用。 Router 为了解决客户端路由问题,我将 Router 引入了 microfe。与常见的客户端路由器不同,microf 的功能有限,它不解析页面而是微应用。假设我们有一个URL /content/detail/13 和一个ContentMicroApp。在这种情况下,microfe 将URL解析为 /content/,它将调用ContentMicroApp /detail/13 URL部分。 MicroAppStore 为了解决微应用到微应用客户端的通信,我将MicroAppStore引入了 microfe。它具有与Redux库类似的功能,区别在于:它对异步数据结构更改和reducer 声明更灵活。 服务器端部分在实现上可能稍微复杂一些,但结构更简单。它只包含两个主要部分 StitchingServer 和许多MicroAppServer。 MicroAppServer MicroAppServer 的最小功能可以概括为 init 和 serve。 虽然 MicroAppServer 首先启动它应该做的是使用 微应用声明 调用 SticthingServer 注册端点,该声明定义了 MicroAppServer 的微应用 依赖关系, 类型 和 URL架构。我认为没有必要提及服务功能,因为没有什么特别之处。 StitchingServer StitchingServer 为 MicroAppServers 提供注册端点。当 MicroAppServer 将自己注册到 StichingServer 时,StichingServer 会记录MicroAppServer 的声明。 稍后,StitchingServer 使用声明从请求的URL解析 MicroAppServers。 解析M icroAppServer 及其所有依赖项后,CSS,JS和HTML中的所有相对路径都将以相关的 MicroAppServer 公共URL为前缀。另外一步是为CSS选择器添加一个唯一的 MicroAppServer 标识符,以防止客户端的微应用之间发生冲突。 然后 StitchingServer 的主要职责就是:从所有收集的部分组成并返回一个无缝的HTML页面。 其他实现一览 甚至在2016年被称为微前端之前,许多大公司都试图通过 BigPipe 来解决Facebook等类似问题。如今这个想法正在获得验证。不同规模的公司对该主题感兴趣并投入时间和金钱。例如,Zalando开源了其名为Project Mosaic的解决方案。我可以说,微型和 Project Mosaic.遵循类似的方法,但有一些重要的区别。虽然microfe采用完全分散的路由定义来增强每个微应用的独立性,但Project Mosaic更喜欢每条路径的集中路由定义和布局定义。通过这种方式,Project Mosaic可以实现轻松的A/B测试和动态布局生成。 对于该主题还有一些其他方法,例如使用iframe作为拼接层,这显然不是在服务器端而是在客户端。这是一个非常简单的解决方案,不需要太多的服务器结构和DevOps参与。这项工作只能由前端团队完成,因此可以减轻公司的组织负担,同时降低成本。 已经有一个框架叫做 single-spa。该项目依赖于每个应用的命名约定来解析和加载微应用。容易掌握想法并遵循模式。因此,在您自己的本地环境中尝试该想法可能是一个很好的初步介绍。但是项目的缺点是你必须以特定的方式构建每个微应用,以便他们可以很好地使用框架。 最后的想法 我相信微前端话题会更频繁地讨论。如果该主题能够引起越来越多公司的关注,它将成为大型团队的事实发展方式。在不久的将来,任何前端开发人员都可以在这个架构上掌握一些见解和经验,这真的很有用。 关于本文 译者:@Vincent.W 译文:https://zhuanlan.zhihu.com/p/82965940 作者:@onerzafer 原文:https://hackernoon.com/understanding-micro-frontends-b1c11585a297 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 阿里云开发者社区

茶什i 2020-01-06 17:57:24 0 浏览量 回答数 0

回答

事务:就是被绑定在一起作为一个逻辑工作单元的SQL语句分组,如果任何一个语句操作失败那么整个操作就被失败,以后操作就会回滚到操作前状态,或者是上有个节点。为了确保要么执行,要么不执行,就可以使用事务。要将有组语句作为事务考虑,就需要通过ACID测试,即原子性,一致性,隔离性和持久性。 锁:在所以的DBMS中,锁是实现事务的关键,锁可以保证事务的完整性和并发性。与现实生活中锁一样,它可以使某些数据的拥有者,在某段时间内不能使用某些数据或数据结构。当然锁还分级别的。 扁平化事务:在扁平事务中,所有的操作都在同一层次,这也是平时使用最多的事务,主要限制是不能提交或回滚事务的某一部分,要么都成功要么都回滚。 带保存点的扁平事务:解决了扁平事务的弊端,它允许事务在执行过程中回滚到较早的状态而不是全部回滚,通过在事务中插入保存点,当操作失败后可以选择回滚到最近的保存点处。 链事务:可看做第二种事务的变种,它在事务提交时,会将必要的上下文隐式传递给下一个事务,当事务失败时,可以回滚到最近的事务,不过链事务只能回滚到最近的保存点,而带保存点的扁平化事务是可以回滚到任意一个保存点。 嵌套事务:由顶层事务和子事务构成,类似于树的结构,一般顶层事务负责逻辑处理,子事务负责具体的工作,子事务可以提交,但真正的提交要等到顶层事务的提交,如果顶层事务回滚,那么所有的子事务都将回滚。 分布式事务:在分布式环境中的扁平化事务。 常用的分布式事务解决方案: (1) XA规范,是保证强一致性的刚性事务,实现方式有两段式提交(2PC)和三段式提交(3PC),2PC需要一个事务协调者来保证事务的参与者都完成了第一阶段的准备工作,如果协调者收到了所有的参与者都准备好的消息,就会通知所有的事务执行第二阶段的提交,一般场景下两段式提交已经能很好的解决分布式事务了。然而两阶段在即使只有一个进程发生故障时,也会导致整个系统存在较长时间的阻塞。三段式提交通过增加pre-commit阶段来减少两段式提交提到的系统阻塞时间,三段式提交很少在实际中使用,简单了解就行了。 (2) TCC:是满足最终一致性的柔性事务方案。TCC采用补偿机制,核心的思想是对每一个操作都要注册对应的确认和补偿操作,分为三个阶段,try阶段主要对业务系统进行检测及资源预留,confirm阶段对业务系统进行确认提交,cancel阶段是对业务执行错误,执行回滚释放预留的资源。 (3) 消息一致性方案:基本思路是将本地操作和发送消息封装在一个事务中,保证本地的操作和消息发送要么都成功,要么都失败。下游应用订阅消息,收到消息后执行对应的操作。 (4)GTS:阿里云的全局事务服务,对应的开源版本是Fescar,Fescar基于两段式提交进行改良,剥离了分布式事务方案对数据库在协议支持上的要求,使用Fescar的前提是分支事务中涉及的资源必须支持ACID事务的关系型数据库,分支的提交和回滚都依赖于本地事务来保障。了解即可。

茶什i 2019-12-02 03:14:22 0 浏览量 回答数 0

问题

你需要的是持续的服务改进

sunny夏筱 2019-12-01 21:41:32 7450 浏览量 回答数 3

回答

消息队列有什么优缺点 优点上面已经说了,就是在特殊场景下有其对应的好处,解耦、异步、削峰。 缺点有以下几个: 系统可用性降低 系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,ABCD 四个系统还好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整?MQ 一挂,整套系统崩溃,你不就完了?如何保证消息队列的高可用,可以点击这里查看。 系统复杂度提高 硬生生加个 MQ 进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。 一致性问题 A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。 所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊? 【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊? 【Java问答学堂】11期 es 生产集群的部署架构是什么?每个索引的数据量大概有多少? 【Java问答学堂】12期 项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果? 【Java问答学堂】13期 redis 和 memcached 有什么区别? 【Java问答学堂】14期 redis 都有哪些数据类型?分别在哪些场景下使用比较合适? 【Java问答学堂】15期redis 的过期策略都有哪些?内存淘汰机制都有哪些? 【Java问答学堂】16期如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍 为什么使用消息队列?【Java问答学堂】17期

剑曼红尘 2020-05-14 11:26:41 0 浏览量 回答数 0

问题

为手机应用程序(android、iOS、windowsPhone)添加超声波通信技术

杨冬芳 2019-12-01 20:11:44 1510 浏览量 回答数 1

问题

消息队列有什么优点和缺点?【Java问答学堂】18期

剑曼红尘 2020-05-14 11:26:31 0 浏览量 回答数 1

问题

如何保护MS SSAS 2005以便通过Internet进行HTTP远程访问?

心有灵_夕 2019-12-29 12:55:30 0 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站