一切福田,不離方寸,從心而覓,感無不通。

Category Archives: Backend

RSA密钥之C#格式与Java格式转换

前言 最近由于项目需求,服务端由c#编写,客户端由java编写。通信数据使用RSA非对称加密。但是java和c#生成的密钥格式是不一样的,所以需要转换格式才可以正常使用。网上搜到使用java进行格式转换的代码(如:http://blog.csdn.net/road2010/article/details/40071881 ),本文将给出一种c#的实现方法。 密钥格式 java密钥格式如下: 私钥: MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAKSZSSEdPhv77O5ocnLNGXeQ21qJDArC1+yId+9/pY5bXkZk5vCB49EpfMwNukLv6AJqofThZPNOs1t015fdEYIUnkIc2QVxRwa0xTeFP6N8D4WQXRWs4fNG27JK5kP45s+9KlJtx5hs7G97aMczehIWpHaO6j9inOmjlU8l62KZAgMBAAECgYEAmK3TRtMwRJb33OGnn9OeFumYfy92qxi3X6Hq1o6qDBW2qkd4bImfv+ni6AinyOVuaadt2Y+lq4dKGcCVJzoZvPm1VKxD2y7xKa8/vEbPRiRTt0qnPq9T7UJkpDsiXf/zOMfWdjc3uA1bPnQ65RWHSJ7zAE+Gd7xnyCE5MEyijLECQQDVYqQWDqOVLZ5lJUuIfUIrhv26GvuoTX8v60+opCz4/Mdfh6JlefICVD6SAaYvufXBHVFY26JicNlR62ZOiBoNAkEAxXhsuEnNJNQcQHEVTPZoulbMbTV1VZIDQ1zjG8fvu8sv6IBYcR5+EsC8n3/6RkW8/iCJDzxE++VHzhoSQSoDvQJBAM6/63J/rpndAIrJ7vyJOPLJsc9/U3SH2gMJAT7KC9UXvuldlsixtf3xuEpplKbLjEUXbfklnZm586a+6XqPvoUCQDFotltOLARBBmihYuEE7qNhQHk63QbyJ9rdDP5Qgo2Mg4o7QuXa6VSr4QZPsUGQBX/YiDLFs8ULU3IgV9zyNEkCQADAYR8DctYzg0eBGdcOrDA5Szc62pYrS2wk89wUxyL4FyDL3omkVMKvtu5tccy7Xht2ikJZRqefZ3dS7ASm8/4= 公钥: MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkmUkhHT4b++zuaHJyzRl3kNtaiQwKwtfsiHfvf6WOW15GZObwgePRKXzMDbpC7+gCaqH04WTzTrNbdNeX3RGCFJ5CHNkFcUcGtMU3hT+jfA+FkF0VrOHzRtuySuZD+ObPvSpSbceYbOxve2jHM3oSFqR2juo/Ypzpo5VPJetimQIDAQAB   .NET密钥格式如下: 私钥:

公钥:

  转换实现代码(c#) 格式转换要用到一个开源加密库Bouncy Castle Crypto APIs,官网地址: http://www.bouncycastle.org/csharp/ 具体实现代码如下:

  from:https://www.cnblogs.com/datous/p/RSAKeyConvert.html

龙生   16 May 2019
View Details

Rsa加解密Java、C#、php通用代码 密钥转换工具

之前发了一篇"TripleDes的加解密Java、C#、php通用代码",后面又有项目用到了Rsa加解密,还是在不同系统之间进行交互,Rsa在不同语言的密钥格式不一样,所以过程中主要还是密钥转换问题,为方便密钥转换,写了一个XML和PEM格式的密钥转换工具,文章后面会提供密钥转换工具的下载地址,通过搜索参考和研究终于搞定了在Java、C#和Php都可以通用的加解密代码,整理了Rsa的加解密代码做个记录,以后可以参考,大家应该都知道Rsa算法,这里就不说明了,直接看代码(代码主要是公钥加密私钥解密,密文统一进行base64编码,密钥长度为2048): Java版本:

  C#版本:

  PHP版本:

Rsa加解密C#和Java、php使用的密钥格式不一样,这里提供一个密钥转换工具:Rsa密钥转换工具v2.0   参考 https://www.cnblogs.com/jaamy/p/6118814.html

龙生   16 May 2019
View Details

接口与抽象类的区别

一个类可以实现多个接口,但却只能继承最多一个抽象类。 抽象类可以包含具体的方法;接口的所有方法都是抽象的。 抽象类可以声明和使用字段;接口则不能,但可以创建静态的final常量。 抽象类中的方法可以是public、protected、private或者默认的pagckage;接口的方法都是public。 抽象类可以定义构造函数;接口不能。

龙生   10 May 2019
View Details

谈谈微服务中的 API 网关(API Gateway)

前言 又是很久没写博客了,最近一段时间换了新工作,比较忙,所以没有抽出来太多的时间写给关注我的粉丝写一些干货了,就有人问我怎么最近没有更新博客了,在这里给大家抱歉。 那么,在本篇文章中,我们就一起来探讨一下 API 网关在整个微服务分布式架构中的一个作用。 背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中,举个例子。 在一个电商系统中,查看一个商品详情页,这个商品详情页包含商品的标题,价格,库存,评论等,这些数据对于后端来说可能是位于不同的微服务系统之中,可能我后台的系统是这样来拆分我的服务的: 产品服务 – 负责提供商品的标题,描述,规格等。 价格服务 – 负责对产品进行定价,价格策略计算,促销价等。 库存服务 – 负责产品库存。 评价服务 – 负责用户对商品的评论,回复等。 现在,商品详情页需要从这些微服务中拉取相应的信息,问题来了? 问题 由于我们使用的服务系统架构,所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果,那么如何才能访问各个服务呢? 按照微服务设计的指导原则,我们的微服务可能存在下面的问题: 服务使用了多种协议,因为不同的协议有不同的应场景用,比如可能同时使用 HTTP, AMQP, gRPC 等。 服务的划分可能随着时间而变化。 服务的实例或者Host+端口可能会动态的变化。 那么,对于前端的UI需求也可能会有以下几种: 粗粒度的API,而微服务通常提供的细粒度的API,对于UI来说如果要调用细粒度的api可能需要调用很多次,这是个不小的问题。 不同的客户端设备可能需要不同的数据。Web,H5,APP 不同设备的网络性能,对于多个api来说,这个访问需要转移的服务端会快得多 以上,就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢? 这种情况下,我们就需要一个今天要讲的这个东西, API 网关(API Gataway)。 API 网关 下面是百度上针对于 API 网关的介绍: API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,为每个客户端提供一个定制的API。它可能还具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。 API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。 Chris Richardson 在他的博客中把 API 网关划分为以下两种: 单节点 API 网关 Backends for frontends 网关 单节点网关 单节点的 API网关为每个客户端提供不同的API,而不是提供一种万能风格的API。 这个网关和微软在 eShop 项目中推荐的网关是一致的。 更多详细信息我会在下文进行说明。 Backends for frontends 网关 这种模式是针对不同的客户端来实现一个不同的API网关。 落地方案 我一直在寻思一种最佳的 API 网关的落地方案,以上两种 API 网关有什么问题呢? 通常情况下, […]

龙生   07 May 2019
View Details

upstream timed out

报错信息:

  解决办法: server { listen       80; server_name  *.xywy.com ;         large_client_header_buffers 4 16k; #客户请求头缓冲大小 nginx默认会用client_header_buffer_size这个buffer来读取header值,如果header过大,它会使用large_client_header_buffers来读取如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request求行如果超过buffer,就会报HTTP 414错误(URI Too Long)nginx接受最长的HTTP头部大小必须比其中一个buffer大,否则就会报400的HTTP错误(Bad Request)。         client_max_body_size 300m; #指令指定允许客户端连接的最大请求实体大小,它出现在请求头部的Content-Length字段. 如果请求大于指定的值,客户端将收到一个"Request Entity Too Large" (413)错误. 记住,浏览器并不知道怎样显示这个错误.         client_body_buffer_size 128k; 这个指令可以指定连接请求实体的缓冲区大小。 如果连接请求超过缓存区指定的值,那么这些请求实体的整体或部分将尝试写入一个临时文件。 默认值为两个内存分页大小值,根据平台的不同,可能是8k或16k。 当请求头中的Content-Length字段小于指定的buffer size,那么Nginx将使用较小的一个,所以nginx并不总是为每一个请求分配这个buffer size大小的buffer。         proxy_connect_timeout 600; 说明 该指令设置与upstream server的连接超时时间,有必要记住,这个超时不能超过75秒。 这个不是等待后端返回页面的时间,那是由proxy_read_timeout声明的。如果你的upstream服务器起来了,但是hanging住了(例如,没有足够的线程处理请求,所以把你的请求放到请求池里稍后处理),那么这个声明是没有用的,由于与upstream服务器的连接已经建立了。         proxy_read_timeout 600; 说明 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间,而是两次reading操作的时间。         proxy_send_timeout 600; 说明 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间,而是在两次write操作期间。如果超时后,upstream没有收到新的数据,nginx会关闭连接         proxy_buffer_size 64k; 该指令设置缓冲区大小,从代理后端服务器取得的第一部分的响应内容,会放到这里. 小的响应header通常位于这部分响应内容里边. 默认来说,该缓冲区大小等于指令 proxy_buffers所设置的;但是,你可以把它设置得更小.         proxy_buffers   4 32k; 该指令设置缓冲区的大小和数量,从被代理的后端服务器取得的响应内容,会放置到这里.         proxy_busy_buffers_size 64k; 默认值: proxy_busy_buffers_size proxy_buffer_size * 2; 上下文: http, server, location, if TODO: Description. buffer工作原理 首先第一个概念是所有的这些proxy buffer参数是作用到每一个请求的。每一个请求会安按照参数的配置获得自己的buffer。proxy buffer不是global而是per request的。 proxy_buffering 是为了开启response buffering of the proxied […]

龙生   05 May 2019
View Details

springboot测试的时候status(),content()方法报错

  是因为静态导入的原因,只要导入:

然后就OK了。   from:https://blog.csdn.net/qq_21549989/article/details/78873229

龙生   30 Apr 2019
View Details

PHP上传大小限制修改

PHP开发中上传是很常见也是很重要的一点,而PHP上传的大小是被限制的,为了更好的起到PHP上传的速度,我们要修改上传大小限制,好了!我们一起来看看是如何修改PHP上传限制的吧! 一般的文件上传,除非文件很小.就像一个5M的文件,很可能要超过一分钟才能上传完. 但在php中,默认的该页最久执行时间为 30 秒.就是说超过30秒,该脚本就停止执行. 这就导致出现 无法打开网页的情况. 这时我们可以修改 max_execution_time 在php.ini里查找 1 max_execution_time 默认是30秒.改为 1 max_execution_time = 0 0表示没有限制 2. 修改 post_max_size 设定 POST 数据所允许的最大大小。此设定也影响到文件上传。 php默认的post_max_size 为2M.如果 POST 数据尺寸大于 post_max_size $_POST 和 $_FILES superglobals 便会为空. 查找 post_max_size .改为 1 post_max_size = 150M 3. 很多人都会改了第二步.但上传文件时最大仍然为 8M. 为什么呢.我们还要改一个参数upload_max_filesize 表示所上传的文件的最大大小。 查找upload_max_filesize,默认为8M改为 1 upload_max_filesize = 100M 另外要说明的是,post_max_size 大于 upload_max_filesize 为佳. 更多上传文章: 在PHP程序中,常常会遇到这种问题,上传附件时明明成功上传了很多附件,如图片等,但实际上只存在20个附件,或者直接报错无法上传。 如何突破php上传多个文件的max_file_uploads限制难题 本篇文章主要介绍了禅道附件大小的限制、PHP上传文件大小限制,对于PHP教程有兴趣的同学可以参考一下。 禅道附件大小的限制、PHP上传文件大小限制 以上就是PHP上传大小限制修改的详细内容,更多请关注php中文网其它相关文章!   from:http://www.php.cn/php-weizijiaocheng-387028.html

龙生   30 Apr 2019
View Details

解决- schema_reference.4: Failed to read schema document 'http://www.springframe

http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd">  <!-- 把后面的3.x去掉 --> ——————— 作者:大道至简_lyon 来源:CSDN 原文:https://blog.csdn.net/a5601564/article/details/51585232 版权声明:本文为博主原创文章,转载请附上博文链接!

龙生   29 Apr 2019
View Details

浅谈MVC和MVVM模式

MVC I’m dating with a model… and a view, and a controller. 众所周知,MVC 是开发客户端最经典的设计模式,iOS 开发也不例外,但是 MVC 有让人无法忽视的严重问题。 MVC, short for Massive View Controller 在通常的开发中,除了简单的 Model、View 以外的所有部分都被放在了 Controller 里面。Controller 负责显示界面、响应用户的操作、网络请求以及与 Model 交互。这就导致了 Controller: 逻辑复杂,难以维护。 和 View 紧耦合,无法测试。   于是微软的大牛提出了 MVVM Model View ViewModel 既然 View 和 Controller 是一对好基友,在 MVVM 里面,干脆把它们当做 View。 现在将原来 Controller 的部分职责拆分出来由 View Model 承担,主要包括: 校验用户输入。 网络请求。 展示层的逻辑,比如格式化字符串。 其他不能放入 Model,与 View 无关的逻辑。 原来的 Controller 现在只负责绑定 View 和 ViewModel。值得注意的是,View Model 不包含与 View 直接关联的部分。一般来说,只要代码中没有#import <UIKit/UIKit.h>即可。 MVVM 的优点 MVVM 兼容 MVC,可以先创建一个简单的 View Model,再慢慢迁移。 MVVM 使得 app 更容易测试,因为 View Model 部分不涉及 […]

龙生   29 Apr 2019
View Details

领域模型、贫血模型、充血模型概念总结

领域模型  领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 贫血模型是指领域对象里只有get和set方法(POJO),所有的业务逻辑都不包含在内而是放在Business Logic层。 优点是系统的层次结构清楚,各层之间单向依赖,Client->(Business Facade)->Business Logic->Data Access Object。可见,领域对象几乎只作传输介质之用,不会影响到层次的划分。 该模型的缺点是不够面向对象,领域对象只是作为保存状态或者传递状态使用,它是没有生命的,只有数据没有行为的对象不是真正的对象,在Business Logic里面处理所有的业务逻辑,对于细粒度的逻辑处理,通过增加一层Facade达到门面包装的效果。 在使用Spring的时候,通常暗示着你使用了贫血模型,我们把Domain类用来单纯地存储数据,Spring管不着这些类的注入和管理,Spring关心的逻辑层(比如单例的被池化了的Business Logic层)可以被设计成singleton的bean。 假使我们这里逆天而行,硬要在Domain类中提供业务逻辑方法,那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦,比如:bean之间的引用,可能引起大范围的bean之间的嵌套构造器的调用。 贫血模型实施的最大难度在于如何梳理好Business Logic层内部的划分关系,由于该层会比较庞大,边界不易控制,内部的各个模块之间的依赖关系不易管理,可以考虑这样这样的实现思路: (1)铺设扁平的原子业务逻辑层,即简单的CRUD操作(含批量数据操作); (2)特定业务清晰的逻辑通过Facade层来组装原子操作实现。 (3)给业务逻辑层实施模块划分,保持模块之间的松耦合的关系。 举例说明: 原子业务逻辑层(Service)提供了用户模型的条件查询方法: List<User> queryUser(Condition con) Facade层则提供了一种特定的业务场景的分子接口,满足18岁的中国公民,内部实现调用的正是上述的原子接口: List<User> queryAdultChinese() Facade、Service层纵向划分为几个大的领域包:用户、内容和产品。   充血模型层次结构和上面的差不多,不过大多业务逻辑和持久化放在Domain Object里面,Business Logic只是简单封装部分业务逻辑以及控制事务、权限等,这样层次结构就变成Client->(Business Facade)->Business Logic->Domain Object->Data Access Object。 它的优点是面向对象,Business Logic符合单一职责,不像在贫血模型里面那样包含所有的业务逻辑太过沉重。 缺点是如何划分业务逻辑,什么样的逻辑应该放在Domain Object中,什么样的业务逻辑应该放在Business Logic中,这是很含糊的。即使划分好了业务逻辑,由于分散在Business Logic和Domain Object层中,不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去,而在Domian Logic又包含了持久化,对于开发者来说这十分混乱。  其次,如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点,它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍,完全属于重复劳动。 使用RoR开发时, 每一个领域模型对象都可以具备自己的基础业务方法,通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。 充血模型的层次和模块的划分是一门学问,对开发人员要求亦较高,可以考虑定义这样的一些规则: (1)事务控制不要放在领域模型的对象中实现,可以放在facade中完成。 (2)领域模型对象中只保留该模型驱动的一般方法,对于业务特征明显的特异场景方法调用放在facade中完成   from:https://www.cnblogs.com/zjoch/p/4435549.html

龙生   29 Apr 2019
View Details
1 114 115 116 283