bind

@ApiImplicitParam： 作用在方法上，表示单独的请求参数 参数： 1. name ：参数名。 2. value ： 参数的具体意义，作用。 3. required ： 参数是否必填。 4. dataType ：参数的数据类型。 5. paramType ：查询参数类型，这里有几种形式： 类型 作用 path 以地址的形式提交数据 query 直接跟参数完成自动映射赋值 body 以流的形式提交 仅支持POST header 参数在request headers 里边提交 form 以form表单的形式提交 仅支持POST 在这里我被坑过一次：当我发POST请求的时候，当时接受的整个参数，不论我用body还是query，后台都会报Body Missing错误。这个参数和SpringMvc中的@RequestBody冲突，索性我就去掉了paramType，对接口测试并没有影响。 @ApiImplicitParams： 用于方法，包含多个 @ApiImplicitParam： 例： @ApiOperation("查询测试") @GetMapping("select") //@ApiImplicitParam(name="name",value="用户名",dataType="String", paramType = "query") @ApiImplicitParams({

作者：p1g3@D0g3 原文链接: https://payloads.info/ 本文为作者投稿，Seebug Paper 期待你的分享，凡经采用即有礼品相送！ 投稿邮箱：paper@seebug.org 这一周把时间都花在学习RMI上了...在很多位师傅的帮助下，终于搞懂了RMI是个什么东西，他的攻击流程是怎么样的，遂记录一篇笔记。 RMI是什么? RMI（Remote Method Invocation），是一种跨JVM实现方法调用的技术。 在RMI的通信方式中，由以下三个大部分组成： Client Registry Server 其中Client是客户端，Server是服务端，而Registry是注册中心。 客户端会Registry取得服务端注册的服务，从而调用服务端的远程方法。 注册中心在RMI通信中起到了一个什么样的作用？我们可以把他理解成一个字典，一个负责网络传输的模块。 服务端在注册中心注册服务时，需要提供一个key以及一个value，这个value是一个远程对象，Registry会对这个远程对象进行封装，使其转为一个远程代理对象。当客户端想要调用远程对象的方法时，则需要先通过Registry获取到这个远程代理对象，使用远程代理对象与服务端开放的端口进行通信，从而取得调用方法的结果。 RMI我认为实际上更偏向于面向接口编程，客户端不需要具体的接口实现类

Consul服务器配置 微服务带来最大的好处就是把整个大项目分割成不同的服务，运行在不同服务器上，实现解耦和分布式处理。微服务虽然有很多好处，但是也会有不好的一方面。任何事物都会有两面性，在微服务里面运维会是一个很大的难题，如果有一天我们的服务数量非常的多，然后我们又不知道哪一个服务在什么机器上。 可能会有人说这部分直接写在程序的配置里面就好了，当我们服务少的时候是可以这么做的，也允许这么做，但是在实际当中我们要尽量避免这么做，比如说我们某一个服务，地址换了，那么我们设计的相关代码就得修改重新部署；又或者说我们有一天上线一个新服务或者下线一个服务，这时候我们又得修改程序代码，这是非常不合理的做法。那么有没有什么可以解决这样的问题呢？这里就需要用到我们的服务注册和发现了。 结构对比 没有服务注册发现的结构 <center>没有服务发现的架构</center> 上面图片我们可以看到在没有服务注册发现的时候一个调用者需要维护多个服务的ip和端口，这是非常不好的做法，当我们服务进行调整的时候就有可能导致服务调用失败，还有服务器更换服务器，上下新服务，都会受到影响。将来某一个服务节点出现问题，排查对于程序和运维人员来说都是一场很大的灾难，因为不知道哪一个节点出了问题，需要每一台服务器的去排查。 而当我们有使用服务注册发现之后的结构体是什么样子的呢？ 有服务注册发现的结构 <center

写在前面 最近一两年预研加开发android双系统；中途用过不少开源代码或者研读过大牛BLOG，现开放双系统设计原理来回报社区。 备注：我是在android6.0上实现的。 这个项目的原型来自于，哥伦比亚大学虚拟化研究室的一篇论文(也有一个DEMO)，后来一个以色列公司cellrox在2014年进行了商业化，2015年的时候浙大一个操作系统研究室也出了一个DEMO(名称叫Condroid)。 哥大论文地址：http://systems.cs.columbia.edu/projects/cells/ 浙大项目地址：http://condroid.github.io/ 以色列公司官网：http://www.cellrox.com/ 浙大的项目本来有源码的后来取消掉了，剩下文档了，对android源码比较熟悉，能复原代码的。 Android 6.0 huawei 6p nexus : fastboot img https://pan.baidu.com/s/1G1risnbT0Usy_NL6VDbovQ 原理： 同docker、lxc、cells的原理一样，利用kernel中的namespace+cgroup来实现android容器的。 启动篇： 必须要有一个能启动init进程的容器生成进程，kernel启动一个init以后，根据rc文件启动一个容器生成器进程，我姑且叫celld

ASP.NET Core引入了Options模式，使用类来表示相关的设置组。简单的来说，就是用强类型的类来表达配置项，这带来了很多好处。利用了系统的依赖注入，并且还可以利用配置系统。它使我们可以采用依赖注入的方法直接使用绑定的一个POCO对象，这个POCO对象就叫做Options对象。也可以叫做配置对象。 以下大多内容来自官方文档，我只是个翻译官或者叫搬运工吧！ 引入Options扩展包 PM>Package-install Microsoft.Extensions.Options 绑定分层配置 在appsetting.json文件增加如下配置 "Position": { "Title": "Editor", "Name": "Joe Smith" } 创建以下 PositionOptions 类： public class PositionOptions { public const string Position = "Position"; public string Title { get; set; } public string Name { get; set; } } 选项类： 必须是包含公共无参数构造函数的非抽象类。 类型的所有公共读写属性都已绑定。 不会绑定字段。 在上面的代码中，Position 未绑定。 由于使用了 Position 属性

基于TCP协议网上聊天程序 引言 21世纪是一个以网络为核心的信息时代，要实现信息化，就必须依靠完善的网络。而随着计算机技术和通讯技术的迅猛发展，计算机网络已经渗透到各个应用领域，其中最突出的是以TCP/IP协议为核心的Internet网络发展最为迅速。因此，计算机应用程序的开发也由传统单机处理模式，转向为多机通信为主的网络应用开发。 1设计任务 1.1系统目标 综合应用计算机网络理论知识、程序设计语言和网络服务器平台，对目标系统进行分析、设计、实现，最后完成必要的测试。在深入理解计算机网络基本原理的基础上，将书本上抽象的概念与具体的实现技术相结合，体会网络协议的设计与实现的过程，以及专业技术人员所使用的基本方法与技巧。基于TCP协议实现一简单的聊天程序实现网上聊天，包括服务器和客户端。要求： （1）支持多人聊天 （2）客户端具有图形化用户界面 1.2系统功能 服务器端运行稳定，客户端具有图形化用户界面，且使用简便。服务器端和客户端可以运行在多个系统平台，具有良好的兼容性能。服务器端和客户端功能独立，可以运行在同一台计算机上或不同的计算机上，具有良好的灵活性。 具体功能： （1）用户注册，用户的密码采用MD5算法就行加密； （2）用户登录，在密码框中，用户输入的密码显示为“*”； （3）显示在线用户，用户登录或退出成功，都会刷新在线用户列表； （4）支持多人聊天，聊天发送的消息

源码地址： GitHub·点这里 || GitEE·点这里 一、基础组件简介 1、Dubbo框架 Dubbo服务化治理的核心框架，之前几年在国内被广泛使用，后续由于微服务的架构的崛起，更多的公司转向微服务下成熟的技术栈，但是Dubbo本身确实是非常优秀的框架。 常见的应用迭代和升级的过程基本如下： 当应用访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。 随着垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。 伴随业务发展，服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。 而Dubbo框架的核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。正好可以解决上述业务发展的痛点。 2、微服务框架 SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线

<!--解决JDK8以上版本 JAXB问题--> < dependency > < groupId > javax.xml.bind </ groupId > < artifactId > jaxb-api </ artifactId > < version > 2.3.0 </ version > </ dependency > < dependency > < groupId > com.sun.xml.bind </ groupId > < artifactId > jaxb-impl </ artifactId > < version > 2.3.0 </ version > </ dependency > < dependency > < groupId > com.sun.xml.bind </ groupId > < artifactId > jaxb-core </ artifactId > < version > 2.3.0 </ version > </ dependency > < dependency > < groupId > javax.activation </ groupId > < artifactId > activation </ artifactId > < version > 1.1.1 </ version > </ dependency

Netty 总算总结完了，小编 也是长舒了一口气。有太多读者私信我让我总结 Netty 了，因为经常会在面试中碰到 Netty 相关的问题。 全文采用大家喜欢的与面试官对话的形式展开。 如果大家觉得 小编 总结的不错的话，不妨转发分享鼓励一下！ 概览： Netty 是什么？ 为什么要用 Netty？ Netty 应用场景了解么？ Netty 核心组件有哪些？分别有什么作用？ EventloopGroup 了解么?和 EventLoop 啥关系? Bootstrap 和 ServerBootstrap 了解么？ NioEventLoopGroup 默认的构造函数会起多少线程？ Netty 线程模型了解么？ Netty 服务端和客户端的启动过程了解么？ Netty 长连接、心跳机制了解么？ Netty 的零拷贝了解么？ Netty 是什么？ ‍ 面试官 ：介绍一下自己对 Netty 的认识吧！小伙子。 我 ：好的！那我就简单用 3 点来概括一下 Netty 吧！ Netty 是一个 基于 NIO 的 client-server(客户端服务器)框架，使用它可以快速简单地开发网络应用程序。 它极大地简化并优化了 TCP 和 UDP 套接字服务器等网络编程,并且性能以及安全性等很多方面甚至都要更好。 支持多种协议 如 FTP，SMTP，HTTP 以及各种二进制和基于文本的传统协议。

依赖注入 当A类需要依赖于B类，也就是说需要在A类中实例化B类的对象来使用时候，如果B类中的功能发生改变，也会导致A类中使用B类的地方也要跟着修改，导致A类与B类高耦合。这个时候解决方式是，A类应该去依赖B类的接口，把具体的类的实例化交给外部。 就拿我们业务中常用的通知模块来说。 <?php /** * 定义了一个消息类 * Class Message */ class Message { public function seed () { return 'seed email' ; } } /* * 订单产生的时候 需要发送消息 */ class Order { protected $messager = '' ; function __construct () { $this -> messager = new Message (); } public function seed_msg () { return $this -> messager -> seed (); } } $Order = new Order (); $Order -> seed_msg (); 上面的代码是我们传统的写法。首先由个消息发送的类。然后在我们需要发送消息的地方，调用发送消息的接口。 有一天你需要添加一个发送短信的接口以满足不同的需求。 那么你会发现你要再 Message 类里面做修改。