首页 文章 精选 留言 我的

精选列表

搜索[最权威安装],共10030篇文章
优秀的个人博客,低调大师

简单的clean架构实践

参考 参考的是学习 CleanArchitecture 心得体会 参考的代码是brzhang的项目 Clean架构 一直都想学Clean架构,今天终于实践了一个简单的CleanDemo,对Clean架构有了进一步的认识。其实Clean就是在MVP架构的基础上做进一步的分层,让每一层更薄,使得代码复用性更高,更易于测试,耦合度更小。 但是最大的缺点就是要定义很多类,很多接口,就一个小小的连个界面,几个简单的功能也要写很多代码,如果用在小项目上的话感觉有点大材小用,所以这种架构一般应用于中大型项目更划算吧。不过应用于小项目拿来练手也是可以的 对架构的简单理解 先上googlesample的图 googleSample uncle-Bob的图 uncle-bob 其实两幅图大体是一样的,主要分三层,分别是DataLayer,DomainLayer,PresentationLayer,依次由低到高,每一层只依赖它的下面一层,而且用上响应式编程如rxjava的话,一般是DataLayer,DomainLayer提供或进一步封装可被观测的对象,PresentationLayer是观测者,不过我看了几个例子都是用了响应编程了 DataLayer 例如这个目录 dataLayer 核心repository 具体结构 数据层,最底层,一般这个层是提供原始的数据接口的,方便给DomainLayer提供数据,至于它怎么实现获取数据,DomainLayer就不用管,你调用就是。可以看到上面核心的还是要有个Repository这个类,但因为界面要用的数据来源可以是本地数据库(Local),也可以使网络获取(remote)的。这种情况缓存功能会遇到,这样就是可像上图那样定义一个接口,然后定义不同实现这个接口的类,一个local的,一个remote的。至于具体怎么实现,那就随便你使用哪种方式了,比如可以数据库框架Realm,Room,GreenDao,网络请求比如Retrofit,Okhttp3那些。而且这一层有个特点,如果不使用数据库(因为用数据库肯定会用到Android的Context),那么这一层代码是不涉及Android库的,这样的话可以直接用Junit测试这一层。 DomainLayer domain 中间层,他完全不知道有一个PresentationLayer存在,只知道有DataLayer,他可以基于这些数据,做进一步的处理封装,对,主要职责就是控制DataLayer对数据做增删改查。 比如这有个例子 public Observable<List<SampleModel>> getDatasFromMutil(){ return Observable.concat(localSampleRepository.lists(100,1),remoteSampleRepository.lists(100,1)) .first(new Func1<List<SampleModel>, Boolean>() { @Override public Boolean call(List<SampleModel> sampleModels) { // TODO: 2017/10/6 这里可以做一缓存设置,比如缓存时间 Log.d(TAG, "call: >>>>>有无缓存?"+(sampleModels!=null&&sampleModels.size()>0)); return sampleModels!=null&&sampleModels.size()>0; } }).doOnNext(new Action1<List<SampleModel>>() { @Override public void call(List<SampleModel> sampleModels) { // 缓存在数据库 Realm realm = Realm.getDefaultInstance(); realm.beginTransaction(); realm.copyToRealmOrUpdate(sampleModels); realm.commitTransaction(); } }); } 这个方法就是一个Case类里的,功能就是如果本地数据库有缓存的数据就直接取出这个数据并返回,如果没有就从网络获取,并且把请求的数据缓存到本地数据库,这个使用了Rxjava的first,concat操作符来实现,十分巧妙。说到底就是对DataLayer层数据的进一步封装,当然不同的业务你可以灵活定义多个Case分开,如果不涉及Android数据库或SP的话,也是没有Android的代码的 PresentationLayer 显示层 这一层可以做进一步的分层,比如VP层,VVM层,和通常的MVP,MVVM用法差不多

优秀的个人博客,低调大师

简单易懂的SpringCloudSleuth教程

事务mapjvm 大佬对下面的说法是否同意呢 能否比较下zipkin,pinpoint,以及skywalking。该如何选型 回答: 他们都提供了分布式服务跟踪的能力,pinpoint以及skywalking不仅仅提供了分布式服务跟踪的能力,还提供了其他性能监控,是一个APM解决方案。zipkin主要是分布式服务跟踪,同时与SpringCloud进行有效的集成。个人觉得pinpoint以及skywalking部署相对麻烦一些。 江湖上都推荐pingpointzipkin的监控易于搭建,但是监控的东西很简单 pinpoint偏向于中等的分布式规模,拓扑和关系不会做的很深,会限制深度。优势是做的时间比较长,理论上稳定一些。缺点是hbase本身就是一个重度运维中间件,要考虑自身情况 skywalking会倾向于微服务的分布式系统,为自研的探针提供了完善的接入支持,我们目前就在给当当做这个接入当时的支持。同时我们会着重比如服务的依赖关系,服务的统计指标。 我们对于应用,只需要配置应用id,不需要实例id,对容器环境毕竟k8,linkerd友好 zipkin强在生态和范围,国外的绝大多数组件都提供了集成方案,只需要少量修改代码或者配置就可以。 比如linkerd原生就支持zipkin 部署上如果你容量不大,pinpoint负担最大,因为hbase,zipkin和skywalking差不多。存储都可以用es 另外,zipkin和skywalking属于opentracing规范体系下,可以共享相同的手动埋点api,skywalking针对非rpc埋点,甚至只需要标注就可以,零开发成本。而pinpoint是必须学习开发插件的。 这基本上是目前的情况。 不算自己的东西,相对pinpoint,我肯定会喜欢zipkin。我能说不喜欢棒子和他们不靠谱的社区行为么… 还是feign的作者。opentracing起草者之一。 现在数据库水平分片有用mycat的么。。。大部分都是使用sharding-jdbc么。。。mycat坑太多坑的你生不如死 随着分布式服务架构的流行,特别是微服务等设计理念在系统中的应用,系统规模也会变得越来越大,各微服务间的调用关系也变得越来越复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果。 在复杂的微服务架构系统中,几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。那么就带来一系列问题,在业务规模不断增大、服务不断增多以及频繁变更的情况下,如何快速发现问题?如何判断故障影响范围?如何梳理服务依赖以及依赖的合理性?如何分析链路性能问题以及实时容量规划?面对上面这些问题,Spring Cloud Sleuth提供了分布式服务跟踪解决方案。 目录: 一、为什么需要以及什么是分布式服务跟踪系统 二、分布式服务跟踪:SpringCloudSleuth 三、分布式服务跟踪系统其他解决方案 一、为什么需要以及什么是 分布式服务跟踪系统 为什么需要分布式服务跟踪系统 随着分布式服务架构的流行,特别是微服务等设计理念在系统中的应用,业务的调用链越来越复杂。 可以看到,随着业务的发展,系统规模也会变得越来越大,各微服务间的调用关系也变得越来越复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一个复杂的分布式服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或者错误都有可能引起请求最后的失败。同时,缺乏一个自上而下全局的调用id,如何有效的进行相关的数据分析工作?对于大型网站系统,如淘宝、京东等电商网站,这些问题尤其突出。 什么是分布式服务跟踪系统 分布式服务跟踪是整个分布式系统中跟踪一个用户请求的过程(包括数据采集、数据传输、数据存储、数据分析、数据可视化),捕获此类跟踪让我们构建用户交互背后的整个调用链的视图,这是调试和监控微服务的关键工具。Spring Cloud Sleuth是Spring Cloud为分布式服务跟踪提供的解决方案,有了它,我们可以: 提供链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误信息。 可视化各个阶段耗时,进行性能分析 各个调用环节的可用性、梳理服务依赖关系以及优化 数据分析,优化链路:可以得到用户的行为路径,汇总分析应用在很多业务场景。 下面我们来看一个典型的分布式系统请求调用过程,如下图所示: 分布式服务跟踪系统的设计 分布式服务跟踪系统设计目标 低入侵性,应用透明:即作为也业务组件,应当尽可能少入侵或者无入侵其他业务系统,对于使用方透明,减少开发人员的负担。 低损耗:服务调用埋点本身会带来性能损耗,这就需要调用跟踪的低损耗,实际中还会通过配置采样率的方式,选择一部分请求去分析请求路径。 大范围部署,扩展性:作为分布式系统的组件之一,一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性。 埋点与生成日志 埋点即系统在当前节点的上下文信息,可以分为客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间,协议类型、调用方ip和端口,请求的服务名、调用耗时,调用结果,异常信息等,同时预留可扩展字段,为下一步扩展做准备; 收集和存储日志(主要支持分布式日志采集的方案,同时增加MQ作为缓冲) 分析和统计调用链路数据,以及时效性 展现以及决策支持 二、分布式服务跟踪: SpringCloudSleuth 快速入门 在引入Sleuth之前,我们需要做一些准备工作,具体如下所示: 服务注册中心(eureka-server) 微服务应用分别为trace1和trace2(它们都有一个REST接口,其中trace1通过RestTemplate调用trace2的REST接口) 微服务应用trace1和trace2项目基本一样(除配置端口、应用名称和REST的Path),以trace1为示例: pom.xml文件增加依赖(如下所示) 主要代码: 配置文件 运行结果,日志没有没有跟踪信息 我们在浏览器或者postman通过http://localhost:8080/trace1,可以返回trace2相应接口的内容,同时我们看到控制台并没有跟踪信息打印,微服务应用trace1和trace2的日志信息具体如下图所示: 添加跟踪依赖 ,日志信息存在跟踪信息 如何为上面的trace1和trace2添加服务跟踪功能呢?SpringCloudSleuth对于此进行封装,使得我们为应用增加服务跟踪能力的操作非常简单,满足前面所说设计目标(低入侵,应用透明),只需在trace1和trace2的pom.xml依赖管理中增加Spring-cloud-starter-sleuth依赖即可,具体如下所示: <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> 添加sleuth依赖后,分别重启trace1和trace2,再次通过浏览器或者postman调用http://localhost:8080/trace1,可以返回trace2相应接口的内容,同时我们看到控制台日志已经存在跟踪信息,微服务应用trace1和trace2的日志信息具体如下图所示: 从上面的控制台输出内容中,我们看到多出了一些形如[trace1,454445a6a7d9ea44,912a7c66c17214e0,false]的日志信息,而这些元素正是实现分布式服务跟踪的重要组成部分,它们的含义分别如下所示: 第一个值:trace1,它表示应用的名称,也就是配置文件spring.application.name的值。 第二个值:454445a6a7d9ea44,它是SpringCloudSleuth生成的一个ID,称为Trace ID,它用来标识一条请求链路,一条请求链路中包含一个Trace ID,多个Span ID。 第三个值:912a7c66c17214e0,它是SpringCloudSleuth生成的另外一个ID,称为Span ID,它表示一个基本的工作单元,比如发送一个http请求。 第四个值:false,表示是否要将该信息输出到Zipkin等服务中来收集和展示。 上面四个值中的Trace ID 和Span ID是SpringCloudSleuth实现分布式服务跟踪的核心。在一次服务请求链路的调用过程中,会保持并传递同一个Trace ID,从而将整个分布于不同微服务进程中的请求跟踪信息串联起来。例如,在一次前端请求链路中,上面trace1和trace2的Trace ID是相同的。 跟踪原理 分布式服务跟踪系统主要包括下面三个关键点: (1)Trace:它是由一组有相同Trace ID的Span串联形成一个树状结构。为了实现请求跟踪,当请求请求到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识(即前文提到的Trace ID),同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回请求为止,我们通过它将所有请求过程中的日志关联起来; (2)Span:它代表了一个基础的工作单元,例如服务调用。为了统计各处理单元的时间延迟,当前请求到达各个服务组件时,也通过一个唯一标识(即前文提到的Span ID)来标记它的开始、具体过程以及结束。通过span的开始和结束的时间戳,就能统计该span的时间延迟,除此之外,我们还可以获取如事件名称、请求信息等元数据。 (3)Annotation:它用于记录一段时间内的事件。内部使用的最重要的注释是: cs(Client Send):客户端发出请求,为开始跨度 sr(Server Received):服务器已收到请求并开始处理。timestampsr - timestampcs =网络延迟。 ss(Server Send):服务器处理完毕准备发送到客户端。timestampss - timestampsr =服务器上的请求处理时间。 cr(Client Received):客户端接收到服务器响应,为跨度结束。客户端已成功接收到服务器的响应。timestampcr - timestampcs =请求的总时间。 以下是在使用Sleuth的两个微服务之间的调用中请求的行为方式,除了生成唯一标识符并将其添加到应用程序日志之外,还需要在作为请求的一部分的微服务器之间正确传播它们。 抽样收集 我们在对接分析系统时就会碰到一个问题:分析系统在收集跟踪信息的时候,需要收集多少跟踪信息才合适呢?生产环境与开发环境跟踪信息收集比例应该不一致,我们是否可以调整呢?同时,不同业务系统收集比例可能也不一样。 理论上来说,我们收集的跟踪信息越多就可以越好反映出系统的实际运行情况,并给出更精确的预警和分析。但在高并发的分布式系统运行时,大量的请求调用会产生海量的跟踪日志信息,如果收集过多的跟踪信息将会对整个分布式系统的性能造成一定的影响,同时保存大量的日志信息也需要不少的存储开销。所以,在Sleuth中采用了抽象收集的方式来跟踪信息打上标记,也就是我们前面第四个布尔值,它代表了该信息是否要被后续的跟踪信息收集器获取和存储。 默认情况下,Sleuth会使用PercentageBasedSampler实现的抽样策略,以请求百分比的方式配置和收集跟踪信息,默认值0.1(代表收集10%的请求跟踪信息),可以通过配置spring.sleuth.sampler来修改收集的百分比。 与ELK整合 前面随着已经有了跟踪信息,但是由于日志文件都分布在各个服务实例的文件系统上,如果链路上服务比较多,查看日志文件定位问题是一件非常麻烦的事情,所以我们需要一些工具来帮忙集中收集、存储和搜素这些跟踪信息。引入基于日志的分析系统是一个不错的选择,比如ELK平台,SpringCloudSleuth在与ELK平台整合使用时,实际上只需要与负责日志收集的Logstash完成数据对接即可,所以我们需要为logstash准备Json格式的日志输出(SpringBoot应用默认使用logback来记录日志,而logstash自身也有对logback日志工具支持)。与ELK整合架构图如下所示: 与Zipkin整合 虽然通过ELK平台提供的收集、存储、搜索等强大功能,但是缺少对请求链路中各阶段时间延迟的关注,而很多时候我们追溯请求链路的一个原因是为了找出整个链路中出现延迟过高的瓶颈源,或者找出问题服务实例等监控与时间消耗相关的需求,ELK就显得乏力,反而引入Zipkin就能够轻松解决。 Zipkin是Twitter的一个开源项目,它基于Google Dapper实现。我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的Rest API接口来辅助查询跟踪数据以分布式系统的监控程序,通过UI组件帮助我们及时发现系统中出现的延迟升高问题以及系统性能瓶颈根源。下面展示Zipkin的基础架构,它主要由4个核心组件构成: Collector(收集器组件):主要负责收集外部系统跟踪信息,转化为Zipkin内部的Span格式。 Storage(存储组件):主要负责收到的跟踪信息的存储,默认为内存,同时支持存储到Mysql、Cassandra以及Elasticsearch。 Restful API(API组件):提供接口,方便外部系统进行集成。 Web UI(展示组件):基于API开发的自带展示界面,方便进行跟踪信息的查看以及查询,同时进行相关的分析。 与zipkin整合——HTTP收集 sleuth收集跟踪信息通过http请求发送给zipkin server,zipkinserver进行跟踪信息的存储以及提供Rest API即可,Zipkin UI调用其API接口进行数据展示。其大体路流程如下图所示: 代码如何实现呢?主要有两个部分:搭建Zipkin Server、为应用引入zipkin依赖和配置,具体如下所示: (1)搭建Zipkin Server 添加Pom依赖 主要代码 配置文件 (2)为应用引入zipkin依赖和配置 添加Pom依赖 为应用增加配置文件 启动Zipkin Server以及分别重启trace1和trace2,再次通过浏览器或者postman调用http://localhost:8080/trace1,可以返回trace2相应接口的内容,同时我们看到控制台日志已经存在跟踪信息,然后通过浏览器访问http://localhost:9411/,我们可以看到Zipkin对于跟踪信息分析与展示,可以看到请求链路,以及每个span的具体耗时,就能分析进行链路优化、依赖分析等操作,其界面具体如下所示: 与zipkin整合——消息中间件收集 Spring Cloud Sleuth在整合Zipkin时,不仅实现了以Http的方式收集,还实现了通过消息中间件来对跟踪信息进行异步收集。通过结合Spring Cloud Stream,我们可以非常轻松地让应用客户端将跟踪信息输出到消息中间件,同时Zipkin服务端从消息中间件上异步获取这些跟踪信息,具体如下所示: 代码如何实现呢?主要有两个部分:搭建Zipkin Server、为应用引入zipkin依赖和配置,具体如下所示: (1)搭建Zipkin Server 添加Pom依赖 主要代码(使用注解@EnableZipkinStreamServer) 配置文件 (2)为应用引入zipkin依赖和配置 添加Pom依赖 为应用增加配置文件 与Zipkin整合——数据存储 默认情况下,Zipkin Server会将跟踪信息存储在内存中,但是这样就会出现我们重启Zipkin Server时之前收集的跟踪信息丢失的问题。为了解决此问题,Zipkin提供了多种存储方式,比如Mysql、Cassandra以及Elasticsearch,以Mysql为例,我们能够很轻松地为Zipkin Server增加Mysql存储功能。主要有三个步骤即可:第一步,在Mysql中创建数据库并且运行其数据脚本;第二步,为pom添加数据库依赖;第三步,修改配置更换存储方式。更多内容请我另一篇博客《微服务之分布式跟踪系统(springboot+zipkin)》。 (博客地址:http://blog.csdn.net/qq_21387171/article/details/53787019) 与Zipkin整合——API接口 Zipkin不仅提供了Web UI方便用户进行跟踪信息查看与查询,同时还提供了Rest API,方便第三方系统进行集成进行跟踪信息的展示和监控,其提供的API列表如下所示: 三、分布式服务跟踪系统其他解决方案 OpenTracing通过提供平台无关、厂商无关的API,使得开发人员能够方便的添加(或更换)追踪系统的实现。 OpenTracing提供了用于运营支撑系统的和针对特定平台的辅助程序库。下面为其相应的成员以及提供的产品: 分布式服务跟踪系统其他解决方案:Jaeger Jaeger(https://github.com/jaegertracing/jaeger)受到Dapper和Zipkin的启发,从开始就建立了OpenTracing支持,是由Uber Technologies作为开源发布的分布式跟踪系统。它可用于监控基于微服务的体系结构:分布式上下文传播、分布式事务监控、根本原因分析、服务依赖性分析以及性能/延迟优化。其架构图如下所示: 分布式服务跟踪系统其他解决方案: Sky Walking Skywalking (https://github.com/wu-sheng/sky-walking)全链路监控开源项目,也是唯一的国内团队开源的APM监控项目。其架构图如下所示: 最后,附上文章所讲内容的源码下载地址(源码地址:https://github.com/dreamerkr/SpringCloudSleuthExample.git),需要可以进行下载与交流。 https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660396033&idx=1&sn=e4274bb41d68633f1c4838b15ec14dc7&chksm=f7424ee7c035c7f1aa902a54d1dd53ca4d4084e3c08aec908b94eabc6b74839922dccc9be847&mpshare=1&scene=1&srcid=0929y6Jby8qF8lKExFmexHzg#rd

优秀的个人博客,低调大师

为什么Android开发抢手?

具备怎样的技能,才能成为受市场欢迎的Android开发? 一名Andriod开发的技能体现在「实际量级下解决问题的能力」,即高效的产出高质量代码,迅速解决开发中存在的BUG,对于需求提出合理的解决方案。 更重要的是,一枚优秀的Android开发绝不会视野只局限在应用层,「对底层的理解」是决定你是否成为Top5%的关键,也是很多工作几年后的Android开发职业上升的瓶颈。 具体落实到技能点,一名有2~3年工作经验的Android开发,具备以下一半的技能点是合格,全部具备是优秀: 扎实的C++、Java基础 熟悉网络编程,了解常用网络协议 熟悉掌握 Android 界面和交互开发 掌握至少一门数据库语言 至少有一个完整的 Android 应用开发经验 良好的编码风格,沟通能力和团队合作精神,有责任感 在 Google Play 上线过自己的 App,加分 对开源技术有强烈的兴趣和爱好,有个人blog、Github账号,参与或向开发者提交过 bug 和 patch 者优先 优秀Android开发的职业成长路径是怎样的? 在不同的职业发展阶段,Android开发的薪水有非常大的差异,伴随着技能和薪资的提升,一位比较顺利的Android开发的职业成长之路是这样的: 1. 初级Android开发:0~3年 在从事Android开发的前三年,在没有遇到和解决足够多的问题之前,你都是菜鸟。对雇主来说,与其社招只有两年工作经验的Android开发,不如通过校招自己培养,这也是100offer一般只接受2年工作经验以上的程序员的原因。 2. 高级Android 开发:3~5年 这是你快速成长成熟的阶段,此时你可能已经有过一次跳槽经历,已经可以独立带领一个小团队,成为一名技术Leader,或小型创业公司的CTO。 3. 架构师:5~7年 成为一名架构师需要更强大的宏观把控能力,可以从上而下看问题,具备良好的体力和思维能力。 4. 研究员/管理总监:7年/10年以上 7年以上的Android开发如果走技术专业路线,首席架构师/研究员是开发者的最终职业目标。要成为首架/Fellow,不仅需要有扎实的基础,还要具备高情商,以及hands-on写代码的能力。值得一提的是,情商在职业发展的后半段发挥着越来越大的作用,尤其体现在团队沟通,和解决冲突的时候。 当你拿到48个面试机会,如何选择? 如果你一下子收到了48个面试机会,该如何选择呢?换言之,如果分辨出靠谱的公司加入呢?以下是在挑选职业机会中,工作2~3年的你需要考虑的几个维度: 1. 去创业公司还是大公司? 如果你是特别能解决问题,具有强烈的自我驱动力的程序员,建议你去创业公司。在那里,一般你会得到更多的解决实际问题的机会,接受更多的挑战。而大公司比较趋同于流程,如果你愿意在团队中安心地做一颗螺丝钉,在前人已经沉淀地较深的技术基础上学习和修补,那么,大公司也是不错的选择。 2. 这个产品是否值得加入? 优秀的Android工程师一般也具有良好的产品思维,比起公司规模,他们更看重产品的前景。 但是,有一个常见的误区首先需要厘清:用户量并不是判断一款产品值得加入的绝对标准。因为落实到你的目标:一款产品即使用户量再大,你做的不过是其中的一个子集;另一款产品即使用户量目前没那么大,但是如果你看好它,可以陪伴它一起成长,用户量逐渐增长,岂不是更有意义。 介绍一个简单快捷的产品判断方法:在面试中和各种职位的面试官聊产品。 和Founder谈,聊对产品的思考,看他对产品是否有相对长久的规划和坚定的想法; 和技术Leader谈,从他的业务敏感度,可以判断这个公司对技术和产品的重视程度; 和产品经理谈,听专业的PM详细介绍这款产品,了解他对需求的看法; 和自己谈,最后问问自己对这款产品是否真的有兴趣,再靠谱的产品你没兴趣也是白搭。 3. 这个团队是否有牛人值得信赖? 正如投资者往往投的是人,因为靠谱的人常常比靠谱的产品更重要。仔细考察这个团队的背景,如果创始人和合伙人是这个领域的牛人,更重要的是他有过成功的经历,那么,加入其中的风险则可有效降低。在大公司中,跟对一个好领导的重要性也不言而喻。 总之,选择比机遇更重要,面对众多的职业机会保持清醒的头脑,仔细做好基本分析,然后,「自信」地跟着感觉走就是了。 本科/研究生学历+3~5年一线知名互联网工作经验+APP开发经历+Github/Blog账号+优秀的沟通能力+寻求好项目的跳槽意愿 这样的Android开发是整个互联网市场都需要的移动应用开发人才,无论是创业公司还是BAT、外企等大公司,都在100offer的拍卖会上向他们发出了面试邀请。 最后,请记住,成为抢手的Android开发证明了你的技术实力,有大局观和高情商的人才会走得更远。 本文作者:佚名 来源:51CTO

优秀的个人博客,低调大师

🔥 xbatis 1.10.7 正式发版,mybatis 系列最好用简单方便的 ORM !!!

推荐理由: 强、强、强 ,单表?连表?不想连表?让你直接少写 1/3 甚至 2/3 的持久层代码;API 简单 快捷 优雅 简洁 构建 SQL 非常强!用过的 没用过的都来体验,虽然有 AI 了,但是真正好用的 ORM 的还不能忽略的,除非你以后不维护。 1.10.7 - 2026-07-20 1:修复distinct多列在count时优化错误的问题 2:新增count优化开关 3:增强case when,支持多个条件 1.10.6 - 2026-07-02 1:新增 COALESCE 函数 2:新增 Map 结果 强制包含 value 为 null 的 key 3:新增 Map key 下划线转驼峰处理 4:新增 DDL 自动化(自动建表、索引、列新增、序列) 1.10.5 - 2026-06-21 1:修复插入数据时,未拼上 @Table 的 schema 的问题 2:增加局部某个表 leftJoin 禁止优化的功能 3:其他优化 4:增加 SQL 审计 1.10.3 - 2026-05-27 1:@Fetch fetchFilter 强制调用开关 2:数据库识别支持 p6spy jdbc url 格式 3:其他优化 表名 /schema 支持动态设置(非分表行为) 4:crud 支持自己创建的 lambda getter 方法引用例如: .eq(EntityLambdaUtil.createSetter(SysUser.class, "id"), 1) 5:修复单列 Fetch 数据库为 null 时运行异常的问题 6:增加 nested 方法来替代 orNested 和 andNested 7:增加 where 方法平替 and or 动态方法 8:新增 getValueById (获取单列值) 方法 9:QueryChain 增加 mapGroupWithKey 分组功能 1.10.2 - 2026-04-29 1:实现 @Fetch, 支持生效条件 2:in/notIn 单条时,变成 eq/ne 行为 3:其他优化 1.10.1 - 2026-04-27 1: 优化 @Fetch 功能代码 2:实现 @Fetch 更多合并的功能场景(从 2 层到 1 层转变,减少 VO 创建) 3:@Fetch 注解增加逻辑删除策略(支持忽略逻辑删除) 1.10.0 - 2026-04-18 1:修复主动调用了 fetchFilter/fetchEnable 时,可能出现报错的问题(未使用 fetchFilter/fetchEnable 的不影响) 1.9.9 - 2026-04-13 1:增加 partialUpdate 精准 (局部) 修改方法 2:原生 updateBatch 修改增加 null / 默认值忽略设置方法 3:LambdaUtil 类增加 setter/getter Lambda 生成方法 4:@ResultCalcField 注解支持数据库函数 5:修复 exists/notExists 中子查询嵌套子查询时,别名一致导致无法上下级引用的问题 6:增加 join 子查询的简化写法 7:所有 Mp 开头的类 改为 Xbatis 开头 8:优化 selectIgnore 功能,不再要求先 select 9:增加 orderByAsc 方法,减少从 mybatis-plus 迁移到 xbatis 的工作量 10:优化底层代码 11:增加 resultmap 官方动态映射继承 12:所有查询完美兼容 pageHelper 13:对于顶级类的字段增加列为为字段名的 resultMap 映射 14:支持多列 in-notIn 操作 15:@Fetch 支持合并查询(从 2 层到 1 层转变,减少 VO 创建) 1.8.7 更新内容: 1:为了更好的 JAVA+XML 结合,query 和 where 增加 tableAs (实体类,别名) 方法,用于自定义表名别名 2:XbatisConfig 改为 XbatisGlobalConfig 3:增加逻辑删除拦截器 4:update delete 增加 原生 RETURNING (原生) 功能 5:增加原生 sql 查询方法和 update delete RETURNING 功能 6:增加了一个 Mapper 方法拦截器 7:增加 exists/not exists 简易写法 通用 SQL 扩展: //类型支持 实体类,VO和普通POJO SysUser user = sysUserMapper.select(SysUser.class, "select * from t_sys_user where id =?", 1); //支持增删改,且支持返回数据 String user_name = sysUserMapper.executeAndReturning(String.class, "update t_sys_user set user_name=? where id=1 RETURNING user_name", "xxx"); //ORM写法 删除并返回被删除的数据(数据库原生操作) List list = DeleteChain.of(sysUserMapper) .in(SysUser::getId, 1, 2) .returning(SysUser.class) .returnType(SysUser.class) .executeAndReturningList(); //ORM写法 修改并返回修改后的数据(数据库原生操作)适合金额加减操作返回剩余金额 SysUser sysUser = UpdateChain.of(sysUserMapper) .eq(SysUser::getId, 1) .set(SysUser::getUserName, "abc2") .returning(SysUser.class) .returnType(SysUser.class) .executeAndReturning(); Java 代码解读 复制代码 展开代码 ▼ 分表配置 @Data @SplitTable(SysUserSplitter.class) public class SysUser { @TableId private Integer id; @SplitTableKey private Integer groupId; private String nickname; private String username; } Java 代码解读 复制代码 展开代码 ▼ public class SysUserSplitter implements TableSplitter { @Override public boolean support(Class type) { return type == Integer.class ** type == int.class; } @Override public String split(String sourceTableName, Object splitValue) { Integer groupId = (Integer) splitValue; //分成10个表 return sourceTableName + "_" + groupId % 10; } } Java 代码解读 复制代码 展开代码 ▼ 分表就是这么简单,其他操作和常规无异!!! 1.7.7 更新内容: 1:QueryChain,DeleteChain,InsertChain,UpdateChain 支持 BasicMapper 方法 2:支持通用 BasicMapper,可不需要创建多个实体类 Mapper;一个 BasicMapper 即可使用所有功能 3:正式支持单 Mapper (写一个 Mapper 即可) 为什么推荐 xbatis?: xbatis 是一款超级强大的 ORM 框架 1:可多表 join(不再只能单表了) 2:代码分页,xml 还可以分页(可以不用 pagehelper 了) 3:良好的扩展能力:orm+sql 模板 (让 ORM 框架不再死板,扩展性极强) 4:强大的各种数据库适配,可在一套代码中 实现多个数据库适配;真正的 ORM hibernate 都做不到 6:极简的 api 设计,让开发者 不再迷糊 1. 单表 +@Fetch 注解 + fetchFilter 方法 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; private String password; private Integer roleId; private LocalDateTime create_time; @Fetch(source = SysUser.class, property = "roleId", target = SysRole.class, targetProperty = "id") private List sysRoles; } Java 代码解读 复制代码 展开代码 ▼ List list = QueryChain.of(sysUserMapper) .from(SysUser.class) .fetchFilter(SysUserVO::getRoles,where->where.eq(SysRole::getStatus,1)) .returnType(SysUserVO.class) .list(); Java 代码解读 复制代码 fetchFilter 方法是对 @Fetch 注解的增强,没有特殊要求一般,可忽略 2. 单表查询 SysUser sysUser = QueryChain.of(sysUserMapper) .eq(SysUser::getId, 1) .eq(SysUser::getUserName,'admin') .get(); Java 代码解读 复制代码 3.VO 映射 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; //字段名字不一样时 @ResultEntityField(property = "password") private String pwd; } Java 代码解读 复制代码 展开代码 ▼ SysUserVO sysUserVO = QueryChain.of(sysUserMapper) .eq(SysUser::getId, 1) .eq(SysUser::getUserName,'admin') .returnType(SysUserVO.class) .list(); Java 代码解读 复制代码 4. join 查询 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; //字段名字不一样时 @ResultEntityField(property = "password") private String pwd; //映射一个对象 1对1 @NestedResultEntity(target = SysRole.class) prviate SysRole sysRole; //映射多个对象 1对多 @NestedResultEntity(target = SysRole.class) prviate List sysRoles; } Java 代码解读 复制代码 展开代码 ▼ List list = QueryChain.of(sysUserMapper) .from(SysUser.class) .join(SysUser.class, SysRole.class) .returnType(SysUserRoleVO.class) .list(); Java 代码解读 复制代码 还有很多很多超级方便有趣的写法,欢迎大家来使用 https://xbatis.cn 例如: 1 . 多表 join A 内嵌 B B 内嵌 C 都可以 2 . 不使用 join 使用 @Fetch 注解 + fetchFilter 方法实现 将 A JOIN B 变成 query A + query B 3 . 使用 @Paging 注解 实现你的 xml 自动分页 4 . 使用 SQL 模板,让你 ORM 更简单更容易扩展,再也不怕被框架限制了

优秀的个人博客,低调大师

璀璨之星 🔥 xbatis 1.10.6 正式发版,最好用简单方便的 ORM !!!

推荐理由: 强、强、强 ,单表?连表?不想连表?让你直接少写 1/3 甚至 2/3 的持久层代码;API 简单 快捷 优雅 简洁 构建 SQL 非常强!用过的 没用过的都来体验,虽然有 AI 了,但是真正好用的 ORM 的还不能忽略的,除非你以后不维护。 1.10.6 - 2026-07-02 1:新增 COALESCE 函数 2:新增Map结果 强制包含value为null的key 3:新增Map key 下划线转驼峰处理 4:新增DDL 自动化(自动建表、索引、列新增、序列) 1.10.5 - 2026-06-21 1:修复插入数据时,未拼上 @Table 的 schema 的问题 2:增加局部某个表 leftJoin 禁止优化的功能 3:其他优化 4:增加SQL 审计 1.10.3 - 2026-05-27 1:@Fetch fetchFilter 强制调用开关 2:数据库识别支持 p6spy jdbc url 格式 3:其他优化 表名 /schema 支持动态设置(非分表行为) 4:crud 支持自己创建的 lambda getter 方法引用例如:.eq(EntityLambdaUtil.createSetter(SysUser.class, "id"), 1) 5:修复单列 Fetch 数据库为 null 时运行异常的问题 6:增加 nested 方法来替代 orNested 和 andNested 7:增加 where 方法平替 and or 动态方法 8:新增 getValueById (获取单列值) 方法 9:QueryChain 增加 mapGroupWithKey 分组功能 1.10.2 - 2026-04-29 1:实现 @Fetch, 支持生效条件 2:in/notIn 单条时,变成 eq/ne 行为 3:其他优化 1.10.1 - 2026-04-27 1: 优化 @Fetch 功能代码 2:实现 @Fetch 更多合并的功能场景(从 2 层到 1 层转变,减少 VO 创建) 3:@Fetch 注解增加逻辑删除策略(支持忽略逻辑删除) 1.10.0 - 2026-04-18 1:修复主动调用了 fetchFilter/fetchEnable 时,可能出现报错的问题(未使用 fetchFilter/fetchEnable 的不影响) 1.9.9 - 2026-04-13 1:增加 partialUpdate 精准 (局部) 修改方法 2:原生 updateBatch 修改增加 null / 默认值忽略设置方法 3:LambdaUtil 类增加 setter/getter Lambda 生成方法 4:@ResultCalcField 注解支持数据库函数 5:修复 exists/notExists 中子查询嵌套子查询时,别名一致导致无法上下级引用的问题 6:增加join 子查询的简化写法 7:所有 Mp 开头的类 改为 Xbatis 开头 8:优化 selectIgnore 功能,不再要求先 select 9:增加 orderByAsc 方法,减少从 mybatis-plus 迁移到 xbatis 的工作量 10:优化底层代码 11:增加 resultmap 官方动态映射继承 12:所有查询完美兼容 pageHelper 13:对于顶级类的字段增加列为为字段名的 resultMap 映射 14:支持多列 in-notIn 操作 15:@Fetch 支持合并查询(从 2 层到 1 层转变,减少 VO 创建) 1.8.7 更新内容: 1:为了更好的 JAVA+XML 结合,query 和 where 增加 tableAs (实体类,别名) 方法,用于自定义表名别名 2:XbatisConfig 改为 XbatisGlobalConfig 3:增加逻辑删除拦截器 4:updatedelete增加 原生 RETURNING (原生) 功能 5:增加原生 sql 查询方法和update delete RETURNING 功能 6:增加了一个Mapper 方法拦截器 7:增加exists/not exists 简易写法 通用 SQL 扩展: //类型支持 实体类,VO和普通POJO SysUser user = sysUserMapper.select(SysUser.class, "select * from t_sys_user where id =?", 1); //支持增删改,且支持返回数据 String user_name = sysUserMapper.executeAndReturning(String.class, "update t_sys_user set user_name=? where id=1 RETURNING user_name", "xxx"); //ORM写法 删除并返回被删除的数据(数据库原生操作) List list = DeleteChain.of(sysUserMapper) .in(SysUser::getId, 1, 2) .returning(SysUser.class) .returnType(SysUser.class) .executeAndReturningList(); //ORM写法 修改并返回修改后的数据(数据库原生操作)适合金额加减操作返回剩余金额 SysUser sysUser = UpdateChain.of(sysUserMapper) .eq(SysUser::getId, 1) .set(SysUser::getUserName, "abc2") .returning(SysUser.class) .returnType(SysUser.class) .executeAndReturning(); Java 代码解读复制代码 展开代码▼ 分表配置 @Data @SplitTable(SysUserSplitter.class) public class SysUser { @TableId private Integer id; @SplitTableKey private Integer groupId; private String nickname; private String username; } Java 代码解读复制代码 展开代码▼ public class SysUserSplitter implements TableSplitter { @Override public boolean support(Class type) { return type == Integer.class ** type == int.class; } @Override public String split(String sourceTableName, Object splitValue) { Integer groupId = (Integer) splitValue; //分成10个表 return sourceTableName + "_" + groupId % 10; } } Java 代码解读复制代码 展开代码▼ 分表就是这么简单,其他操作和常规无异!!! 1.7.7 更新内容: 1:QueryChain,DeleteChain,InsertChain,UpdateChain 支持 BasicMapper 方法 2:支持通用 BasicMapper,可不需要创建多个实体类 Mapper;一个 BasicMapper 即可使用所有功能 3:正式支持单 Mapper (写一个 Mapper 即可) 为什么推荐 xbatis?: xbatis 是一款超级强大的 ORM 框架 1:可多表 join(不再只能单表了) 2:代码分页,xml 还可以分页(可以不用 pagehelper 了) 3:良好的扩展能力:orm+sql 模板 (让 ORM 框架不再死板,扩展性极强) 4:强大的各种数据库适配,可在一套代码中 实现多个数据库适配;真正的 ORM hibernate 都做不到 6:极简的 api 设计,让开发者 不再迷糊 1.单表 +@Fetch 注解 + fetchFilter 方法 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; private String password; private Integer roleId; private LocalDateTime create_time; @Fetch(source = SysUser.class, property = "roleId", target = SysRole.class, targetProperty = "id") private List sysRoles; } Java 代码解读复制代码 展开代码▼ List list = QueryChain.of(sysUserMapper) .from(SysUser.class) .fetchFilter(SysUserVO::getRoles,where->where.eq(SysRole::getStatus,1)) .returnType(SysUserVO.class) .list(); Java 代码解读复制代码 fetchFilter 方法是对 @Fetch 注解的增强,没有特殊要求一般,可忽略 2. 单表查询 SysUser sysUser = QueryChain.of(sysUserMapper) .eq(SysUser::getId, 1) .eq(SysUser::getUserName,'admin') .get(); Java 代码解读复制代码 3.VO 映射 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; //字段名字不一样时 @ResultEntityField(property = "password") private String pwd; } Java 代码解读复制代码 展开代码▼ SysUserVO sysUserVO = QueryChain.of(sysUserMapper) .eq(SysUser::getId, 1) .eq(SysUser::getUserName,'admin') .returnType(SysUserVO.class) .list(); Java 代码解读复制代码 4. join 查询 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; //字段名字不一样时 @ResultEntityField(property = "password") private String pwd; //映射一个对象 1对1 @NestedResultEntity(target = SysRole.class) prviate SysRole sysRole; //映射多个对象 1对多 @NestedResultEntity(target = SysRole.class) prviate List sysRoles; } Java 代码解读复制代码 展开代码▼ List list = QueryChain.of(sysUserMapper) .from(SysUser.class) .join(SysUser.class, SysRole.class) .returnType(SysUserRoleVO.class) .list(); Java 代码解读复制代码 还有很多很多超级方便有趣的写法,欢迎大家来使用https://xbatis.cn 例如: 1 . 多表 join A 内嵌 B B 内嵌 C 都可以 2 . 不使用 join 使用 @Fetch 注解 + fetchFilter 方法实现 将 A JOIN B 变成 query A + query B 3 . 使用 @Paging 注解 实现你的 xml 自动分页 4 . 使用 SQL 模板,让你 ORM 更简单更容易扩展,再也不怕被框架限制了

优秀的个人博客,低调大师

璀璨之星 🔥 xbatis 1.10.5 正式发版,最好用简单方便的 ORM !!!

推荐理由: 强、强、强 ,单表?连表?不想连表?让你直接少写 1/3 甚至 2/3 的持久层代码;API 简单 快捷 优雅 简洁 构建 SQL 非常强!用过的 没用过的都来体验,虽然有 AI 了,但是真正好用的 ORM 的还不能忽略的,除非你以后不维护。 1.10.5 - 2026-06-21 1:修复插入数据时,未拼上@Table的schema的问题 2:增加局部某个表leftJoin禁止优化的功能 3:其他优化 4:增加SQL审计 1.10.3 - 2026-05-27 1:@Fetch fetchFilter 强制调用开关 2:数据库识别支持 p6spy jdbc url 格式 3:其他优化 表名 /schema 支持动态设置(非分表行为) 4:crud 支持自己创建的 lambda getter 方法引用例如:.eq(EntityLambdaUtil.createSetter(SysUser.class, "id"), 1) 5:修复单列 Fetch 数据库为 null 时运行异常的问题 6:增加 nested 方法来替代 orNested 和 andNested 7:增加 where 方法平替 and or 动态方法 8:新增 getValueById (获取单列值) 方法 9:QueryChain 增加 mapGroupWithKey 分组功能 1.10.2 - 2026-04-29 1:实现 @Fetch, 支持生效条件 2:in/notIn 单条时,变成 eq/ne 行为 3:其他优化 1.10.1 - 2026-04-27 1: 优化 @Fetch 功能代码 2:实现 @Fetch 更多合并的功能场景(从 2 层到 1 层转变,减少 VO 创建) 3:@Fetch 注解增加逻辑删除策略(支持忽略逻辑删除) 1.10.0 - 2026-04-18 1:修复主动调用了 fetchFilter/fetchEnable 时,可能出现报错的问题(未使用 fetchFilter/fetchEnable 的不影响) 1.9.9 - 2026-04-13 1:增加 partialUpdate 精准 (局部) 修改方法 2:原生 updateBatch 修改增加 null / 默认值忽略设置方法 3:LambdaUtil 类增加 setter/getter Lambda 生成方法 4:@ResultCalcField 注解支持数据库函数 5:修复 exists/notExists 中子查询嵌套子查询时,别名一致导致无法上下级引用的问题 6:增加join 子查询的简化写法 7:所有 Mp 开头的类 改为 Xbatis 开头 8:优化 selectIgnore 功能,不再要求先 select 9:增加 orderByAsc 方法,减少从 mybatis-plus 迁移到 xbatis 的工作量 10:优化底层代码 11:增加 resultmap 官方动态映射继承 12:所有查询完美兼容 pageHelper 13:对于顶级类的字段增加列为为字段名的 resultMap 映射 14:支持多列 in-notIn 操作 15:@Fetch 支持合并查询(从 2 层到 1 层转变,减少 VO 创建) 1.8.7 更新内容: 1:为了更好的 JAVA+XML 结合,query 和 where 增加 tableAs (实体类,别名) 方法,用于自定义表名别名 2:XbatisConfig 改为 XbatisGlobalConfig 3:增加逻辑删除拦截器 4:updatedelete增加 原生 RETURNING (原生) 功能 5:增加原生 sql 查询方法和update delete RETURNING 功能 6:增加了一个Mapper 方法拦截器 7:增加exists/not exists 简易写法 通用 SQL 扩展: //类型支持 实体类,VO和普通POJO SysUser user = sysUserMapper.select(SysUser.class, "select * from t_sys_user where id =?", 1); //支持增删改,且支持返回数据 String user_name = sysUserMapper.executeAndReturning(String.class, "update t_sys_user set user_name=? where id=1 RETURNING user_name", "xxx"); //ORM写法 删除并返回被删除的数据(数据库原生操作) List list = DeleteChain.of(sysUserMapper) .in(SysUser::getId, 1, 2) .returning(SysUser.class) .returnType(SysUser.class) .executeAndReturningList(); //ORM写法 修改并返回修改后的数据(数据库原生操作)适合金额加减操作返回剩余金额 SysUser sysUser = UpdateChain.of(sysUserMapper) .eq(SysUser::getId, 1) .set(SysUser::getUserName, "abc2") .returning(SysUser.class) .returnType(SysUser.class) .executeAndReturning(); Java 代码解读复制代码 展开代码▼ 分表配置 @Data @SplitTable(SysUserSplitter.class) public class SysUser { @TableId private Integer id; @SplitTableKey private Integer groupId; private String nickname; private String username; } Java 代码解读复制代码 展开代码▼ public class SysUserSplitter implements TableSplitter { @Override public boolean support(Class type) { return type == Integer.class ** type == int.class; } @Override public String split(String sourceTableName, Object splitValue) { Integer groupId = (Integer) splitValue; //分成10个表 return sourceTableName + "_" + groupId % 10; } } Java 代码解读复制代码 展开代码▼ 分表就是这么简单,其他操作和常规无异!!! 1.7.7 更新内容: 1:QueryChain,DeleteChain,InsertChain,UpdateChain 支持 BasicMapper 方法 2:支持通用 BasicMapper,可不需要创建多个实体类 Mapper;一个 BasicMapper 即可使用所有功能 3:正式支持单 Mapper (写一个 Mapper 即可) 为什么推荐 xbatis?: xbatis 是一款超级强大的 ORM 框架 1:可多表 join(不再只能单表了) 2:代码分页,xml 还可以分页(可以不用 pagehelper 了) 3:良好的扩展能力:orm+sql 模板 (让 ORM 框架不再死板,扩展性极强) 4:强大的各种数据库适配,可在一套代码中 实现多个数据库适配;真正的 ORM hibernate 都做不到 6:极简的 api 设计,让开发者 不再迷糊 1.单表 +@Fetch 注解 + fetchFilter 方法 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; private String password; private Integer roleId; private LocalDateTime create_time; @Fetch(source = SysUser.class, property = "roleId", target = SysRole.class, targetProperty = "id") private List sysRoles; } Java 代码解读复制代码 展开代码▼ List list = QueryChain.of(sysUserMapper) .from(SysUser.class) .fetchFilter(SysUserVO::getRoles,where->where.eq(SysRole::getStatus,1)) .returnType(SysUserVO.class) .list(); Java 代码解读复制代码 fetchFilter 方法是对 @Fetch 注解的增强,没有特殊要求一般,可忽略 2. 单表查询 SysUser sysUser = QueryChain.of(sysUserMapper) .eq(SysUser::getId, 1) .eq(SysUser::getUserName,'admin') .get(); Java 代码解读复制代码 3.VO 映射 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; //字段名字不一样时 @ResultEntityField(property = "password") private String pwd; } Java 代码解读复制代码 展开代码▼ SysUserVO sysUserVO = QueryChain.of(sysUserMapper) .eq(SysUser::getId, 1) .eq(SysUser::getUserName,'admin') .returnType(SysUserVO.class) .list(); Java 代码解读复制代码 4. join 查询 @Data @ResultEntity(SysUser.class) public class SysUserVo { private Integer id; private String userName; //字段名字不一样时 @ResultEntityField(property = "password") private String pwd; //映射一个对象 1对1 @NestedResultEntity(target = SysRole.class) prviate SysRole sysRole; //映射多个对象 1对多 @NestedResultEntity(target = SysRole.class) prviate List sysRoles; } Java 代码解读复制代码 展开代码▼ List list = QueryChain.of(sysUserMapper) .from(SysUser.class) .join(SysUser.class, SysRole.class) .returnType(SysUserRoleVO.class) .list(); Java 代码解读复制代码 还有很多很多超级方便有趣的写法,欢迎大家来使用https://xbatis.cn 例如: 1 . 多表 join A 内嵌 B B 内嵌 C 都可以 2 . 不使用 join 使用 @Fetch 注解 + fetchFilter 方法实现 将 A JOIN B 变成 query A + query B 3 . 使用 @Paging 注解 实现你的 xml 自动分页 4 . 使用 SQL 模板,让你 ORM 更简单更容易扩展,再也不怕被框架限制了

优秀的个人博客,低调大师

权威报告:Java遭Kotlin威胁,2018程序员应该何去何从

最近,Packt 发布了“2018 开发者技能提升报告”,此报告调查了800多名开发人员和技术专家,从应用开发、web开发、安全和系统管理,以及数据四个方面对开发者进行了调查,旨在了解软件开发人员的工具使用情况和技能趋势。 Kotlin是Java强有力的竞争者 在此报告中,Java在编程语言中仍然占据着主导的地位,但是Kotlin可能很快替代Java在移动开发第一位置。在8000名接受调查的用户中,71%的受访者表示,Kotlin是Java强有力的竞争者。 Kotlin 于2011年出现,但直到最近才开始真正吸引工程师的特别青睐。Google 在 2017 年宣布 Kotlin 在 Android Studio 3.0 中完全获得支持,使之成为 Android 开发语言之一。预计到今年年底,Kotlin 将与 Java 展开激烈竞争。 B

优秀的个人博客,低调大师

Hadoop权威指南学习笔记_第一章_初识Hadoop

学习时间:20130701 知识点积累: 数据的存储和分析: 为了实现数据读取的高效,可从多个磁盘并行读取数据,需要解决2个问题: 硬件故障,避免数据丢失 大部分分析任务需要通过某种方式把数据合并起来 相较于其他系统: 关系型数据库管理系统: 网格计算: 高性能计算(High Performance Computing)的方法是将作业分配给一个机器集群,这些机器访问共享文件系统,由一个存储区域网络(Storage Area Network,SAN)进行管理;这非常适用于CPU密集型的作业,但当节点需要访问大数据量时,网络带宽将成为“瓶颈” MapReduce尝试在计算节点本地存储数据,这项“数据本地化”功能成为MapReduce的核心功能 MapReduce检测失败的map或者reduce任务,在健康的机器上重新安排任务,而不需要程序员考虑失败任务的处理机制 志愿计算: 志愿计算项目通过将他们试图解决的问题分成多个块,每个块称为一个工作单元,并将它们发到世界各地的电脑上进行分析 SETI@home问题是CPU高度密集型的,并在接入互联网的不可信的计算机上运行,这些计算机的网速不同,而且数据也不在本地 Hadoop生态圈: Common:一组分布式文件系统和通用I/O的组件与接口(序列化、Java RPC和持久化数据结构) Avro:一种支持高效、跨语言的RPC以及永久存储数据的序列化系统; MapReduce:分布式数据处理模型和执行环境,运行于大型商用机集群; HDFS:分布式文件系统,运行于大型商用机集群; Pig:一种数据流语言和运行环境,用以检索非常大的数据集; Hive:一个分布式、按列存储的数据仓库,管理HDFS中存储的数据,并提供基于SQL的查询语句用以查询数据; HBase:一个分布式、按列存储数据库,使用HDFS作为底层存储,同时支持MapReduce的批量式计算和点查询(随机读取); Zookeeper:一个分布式、可用性高的协调服务;提供分布式锁之类的基本服务用于构建分布式应用; Sqoop:在数据库和HDFS之间高效传输数据的工具 本文转自 xxrenzhe11 51CTO博客,原文链接:http://blog.51cto.com/xxrenzhe/1238932,如需转载请自行联系原作者

优秀的个人博客,低调大师

《VMware Virtual SAN权威指南》一3.9.1 vSphere HA通信网络

3.9.1 vSphere HA通信网络 在非VSAN部署中,vSphere HA代理的通信是通过管理网络进行的;在VSAN环境中,vSphere HA代理的通信是通过VSAN网络进行的。背后的原因是我们希望当网络故障发生时,vSphere HA主机和VSAN主机是位于同一分区(partition)中的,这就避免了故障时因vSphere HA和VSAN判断的分区不同而造成拥有的存储组件和对象集不同所造成的可能的冲突。在VSAN环境下的vSphere HA在默认情况下仍然将管理网络的默认网关用作隔离检测(isolation detection)。我们估计大多数VSAN环境的管理网络和VSAN网络很可能是使用同一个物理网络基础架构的(尤其是在万兆网络情况下)。但是,如果VSAN网络和管理网络是位于不同的物理网络基础架构,建议将默认的vS

优秀的个人博客,低调大师

权威人士对2015年云的十大预测

ZDNet至顶网服务器频道 01月08日 新闻消息: 上图摄于中国杭州——阿里巴巴的总部。(IO公司的CEO George Slessman表示:阿里巴巴将会在2015年成为世界最大的公司,彼时互联网的中心也将转移至亚洲。) 尽管已有迹象显示:2015年的云计算市场将趋于成熟化,这些信号包括合并整合,以及云服务组合的规范化等等,但还有一些只是无关根本的变化,这些变化包括有世界范围内对亚洲的关注不断增长,还有云决策方面新的数据隐私立法的影响。 继去年12月份我们发表的文章《数据中心预测一览》之后,本文总结了今年一些最为有趣的云预测,这些预测分别来自互联网数据中心(IDC),451研究网站(451 Research),IO公司还有戴尔公司。 1. 对数据隐私进行立法以规范云决策 2013年,曾供职于美国中央情报局和国防项目承包商Booz Allen Hamilton的Edward Snowden将美国国家安全局关于PRISM监听项目的秘密文档披露给了《卫报》和《华盛顿邮报》,自此,公众获知:世界范围内的电子通讯均受到政府的秘密监控,这使得数据隐私倍受公众关注,从而引发旨在保护数据隐私的大量新法规产生。 市场研究公司IDC的调查结果显示,在2015年IT业界将会切实体会到这一系列事件的影响。IDC的分析师在其关于2015年的云预测中称:这一年,全球企业云工作负载中有65%将需要符合数据隐私法。 2. 企业由于开源,将逐步发展壮大 IDC称,2015年企业大量开源不太可能,不过确有趋势显示:企业将更多地开源。分析师预测:20%的企业将会发现社区驱动的开源标准和框架有着重要的价值,而到2017年这些标准和框架将会被战略化地应用到实践中。 一些采用开源项目的企业发展势头强劲,著名的案例包括:云架构OpenStack,平台即服务的Cloud Foundry,应用容器引擎标准Docker,还有OpenFlow这个运用软件定义网络标准的云端服务公司。 3. 个性订制的IT自动化技术即将出现 过去的几年里,IT自动化技术呈上升化发展,IT公司愈来愈多的采用DevOps,通过基础架构配置的自动化,以支持软件按周期地连续发布。 但是随着时间的流逝,根据IDC的说法,自动化将会趋于更细致的方向,到2017年的时候,四分之一的IT公司都会支持“用户层级”,也就是说用户可以根据个人需求来定制自己的自动化技术。 4. IaaS(基础设施即服务)服务减少 过去两到三年内,新的IaaS服务不断推出,相应的服务公司也不断出现,IDC预测:服务提供商将对其服务组合进行大规模的变更。分析师表示:在未来的一到两年内,将会有75%的IaaS服务提供商重新设计、重塑和更名自己的服务,或者逐步淘汰相应服务。 5. 服务提供商大规模整合 IO公司是一家基于Phoenix的主机托管服务提供商,其CEO暨联合创始人George Slessman预测:从今年开始,数据中心、主机托管以及云服务提供商之间将会有持续若干年的大规模整合过程。对于这些垂直服务商来说,整合并不是什么新鲜事,但是George Slessman所言及的过程将会以形成“全球数据中心及应用物流网络系统”而最终完成。 6. 新的应用归宿:混合云计算以及主机托管 George Slessman认为:2015年,超过90%的新开发应用将会运行在云上,或者“混合动力主机托管”环境中。 大量的主机托管提供商一直在追求满足混合解决方案的需求,以方便用户将自己的服务器与云服务结合起来。其中一些是类似CenturyLink这样的公司,一小部分是类似IO这样的公司,他们都已经开发出自身的云服务;还有一些像是易Equinix和Telx这样的公司,也已经通过大量不同的服务商建设了接入云服务的数据中心枢纽。 7. 互联网中心将会转到亚洲 George Slessman认为:在2014年上市的中国互联网巨擘阿里巴巴,在IPO(首次公开募股)之后的一年内必将成为世界最大的公司。他认为:这代表着“互联网中心转向亚洲决定性的一步”,阿里巴巴对亚洲起到的作用,相当于英特尔或者硅谷。 阿里巴巴经营着一家类似亚马逊的电子商务网站,但是就像微软这个总部位于华盛顿雷德蒙德的巨头一样,阿里巴巴同时也拥有名为阿里云的云服务业务。阿里巴巴在中国和香港均开设有数据中心,提供从基础云计算到复杂的基于云的数据分析服务。 8. 云安全方面将会维持巨大数额的开销 另一家市场研究公司451Research预测:2015年,在云安全方面的支出将会再次增长并会持续下去。该分析师认为:在云安全方面的企业并购、IPO、风险投资还有私募股权投资将会持续或接近历史上限。 尽管对整个行业而言这是个好消息,但这种趋势只会意味着伴随IT业的新发展,新的漏洞将会出现,从而需要新的安全产品。451 Research的分析师在2015的六项云预测中表示:“在很大程度上云安全将非常活跃”,并表示云安全的发展通常会随着IT业的发展而增长并在发展上稍迟两年左右。 9. 私有云的灵活性会逐渐降低 戴尔公司认为:尽管机动性是云的主要优势之一,2015年私有云基础架构的机动性最终会随着首席信息官们而降低,按需移除融合式基础架构模块的能力将会使得私有云更加灵活并富有吸引力。 10. 专业IT知识价值将会降低 戴尔公司认为:随着越来越多的IT项目被外包,公司对于高度专业认证的依赖将会逐渐减少,产业化和虚拟化技术使得公司可以将所有可用的IT资源视为一体,更多的是着重于使用它们完成什么内容,而不是在每个独立的基础设施上花费大量的资源。 原文发布时间为:2015年01月08日 本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

优秀的个人博客,低调大师

《VMware Virtual SAN权威指南(原书第2版)》一导读

前 言 说到虚拟化及其依赖的底层基础架构,经常会提起一个组件——存储。原因相当简单:在很多环境中,存储是痛点。尽管存储市场已经因为闪存技术的引入发生了变化,很多传统的存储问题得到了缓解,但是很多机构还没能采纳这些新的架构,因而仍然会遇到挑战。存储问题的范围包括运营上的复杂性到性能问题甚至是可用性的限制。这些问题中的大部分都起因于同样的根本问题:老旧的系统架构。这是因为大多数存储平台架构是在虚拟化技术出现之前开发出来的,而虚拟化已经改变了使用这些共享存储平台的方法。某种程度上,可以说是虚拟化迫使存储业界去寻找新的方法来构建存储系统。不再是通过单台服务器连接到单台存储设备(也称为逻辑单元或简写为LUN),虚拟化通常由一台(或多台)物理服务器承载很多虚拟机连接到一个或多个存储设备上。这不仅仅增加了这些存储系统的负载,也改变了工作负载的模

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册