namespace

PHP-FIG 在说啥是PSR-[0-4]规范的之前，我觉得我们有必要说下它的发明者和规范者：PHP-FIG，它的网站是： www.php-fig.org 。就是这个联盟组织发明和创造了PSR-[0-4]规范，膜拜吧，屌丝们！ FIG 是 Framework Interoperability Group（框架可互用性小组）的缩写，由几位开源框架的开发者成立于 2009 年，从那开始也选取了很多其他成员进来，虽然不是 “官方” 组织，但也代表了社区中不小的一块。组织的目的在于：以最低程度的限制，来统一各个项目的编码规范，避免各家自行发展的风格阻碍了程序设计师开发的困扰，于是大伙发明和总结了PSR，PSR是Proposing a Standards Recommendation（提出标准建议）的缩写，截止到目前为止，总共有5套PSR规范，分别是： PSR-0 (Autoloading Standard) 自动加载标准 PSR-1 (Basic Coding Standard) 基础编码标准 PSR-2 (Coding Style Guide) 编码风格向导 PSR-3 (Logger Interface) 日志接口 PSR-4 (Improved Autoloading) 自动加载的增强版，可以替换掉PSR-0了。 接下来的篇目，我们会针对这5套，深入了解下

　　一、在C#中，使用命名空间（Namespace）可以帮助控制自定义类型的作用范围，同时对大量的类型进行组织；使用namespace关键字声明命名空间，命名空间可以嵌套使用： namespace MyNameSpace { namespace MyNestedNameSpace { class MyClass { public void MyFunc() { //do... } } } } 　　1.命名空间默认即为public，没有任何访问限制，不能使用任何访问修饰符； 　　2.在命名空间中的定义的五种基本类型（类class、结构struct、接口interface、枚举enum和委托delegate），只能是public或internal的，默认为internal的； 　　3.每一种类型根据其命名空间的不同会拥有一个唯一名称，即完全限定名称（Fully Qualified Name），例如上面自定义类型MyClass的完全限定名称为MyNameSpace.MyNestedNameSpace.MyClass； 　　※完全限定名称才是CLR看到的实际类型名称； 　　二、使用using关键字引用指定的命名空间，这样可在当前代码范围内免去为每个类型指定命名空间的名称，通过.运算符分隔嵌套的命名空间： using MyNameSpace.MyNestedNameSpace; 　　※此时

一、背景介绍 在使用纯手工维护yaml文件方式完成内网开发和两套测试环境和现网生成环境的核心微服务pod化之后。发现主要痛点如下： 1、工作负载相关的yaml文件维护量巨大，且易出错。（目前内网共有77个工作负载） 2、研发人员对工作负载配置改动的需求比较频繁，例如修改jvm相关参数，增加initcontainer、修改liveness、readiness探针、亲和性与反亲和性配置等，这类的配置严重同质化。 3、每个namespace都存在环境变量、configmap、rbac、pv\pvc解耦类的配置，如果对应的配置未提前创建，则后续创建的工作负载无法正常工作。 随着第二阶段各平台模块的微服务化改造工作的推进，预计每个namespace会分别增加30-40个工作负载，因此需要维护的yaml文件将急剧扩展，手工维护已不现实。因此使用helm来维护k8s应用被提上议事日程。 关于helm的配置文件语法及服务端配置请参考官网手册： https://helm.sh/docs/ 二、需求分析 1、公共配置类 Configmap 每个namespace至少有两个configmap，其中center-config存储了各个环境的mysql、mongodb、redis等基础公共服务的IP、用户名和密码、连接池配置信息等，我们通过集中配置解耦做到代码编译一次镜像，各个环境都能运行。 hb-lan

#1、写一个帮助类DBUtil 方法callWS,访问Wb返回相对应的数据 /** String namespace = “http://tempuri.org/”;//namespace String Url = “http://47.92.68.57:8099/WebServices_Device_Management.asmx?WSDL”; String methodName = “Select”; 有参数的时候： Map<String, Object> params = new HashMap<>(); params.put(“username”, “admin”); params.put(“password”, “123456”); @param nameSpace WS的命名空间 @param methodName WS的方法名 @param wsdl WS的wsdl的完整路径名 @param params WS的方法所需要的参数 @return SoapObject对象 */ public static SoapObject callWS(String nameSpace, String methodName, String wsdl, Map<String, Object> params) { final String SOAP_ACTION = nameSpace

Kubernetes API的使用方式 Kubernetes API属于声明式API编程， 它和常用的命令式编程有一些区别。 通俗的说，命令式编程是第一人称，我要做什么，我要怎么做。 操作系统最喜欢这种编程范式了， 操作系统几乎不用"思考", 只要一对一的将代码翻译成指令就可以了。 而声明式编程则类似于"第二人称"， 也就是你要做什么。 有点"产品经理"和"开发“之间的关系， "产品经理"只负责提需求，而"开发"怎么实现他不并关心。 用户相对Kubernetes就是"产品经理"的角色， 用户只需要给Kubernetes提需求就可以了，比如说你(Kubernetes)给我(用户)创建一个运行Mysql服务的Demployment，这个Deployment运行的Pod镜像是xxxx，运行参数是xxxxx，挂载的数据卷是xxxxx。。。。。 等等。 开发(Kubernetes)接受到这个需求后， 看看 需求是否合理(验证Deployment里面的参数是否正确)，然后就开始创建了。 等待创建成功后，就告诉"产品经理"(用户)Deployment创建成功。 在创建过程中，用户并没有(也不需要)关心服务是如何创建的。 这种操作方式就是声明式API。 对于Kubernetes来说，声明式API最大的难点就在于如何提一个正确的需求了。 所以下面来看看如何给Kubernetes提需求。 API的载体

Kubernetes API的使用方式 比奇小说网 m.biqi.org Kubernetes API属于声明式API编程， 它和常用的命令式编程有一些区别。 通俗的说，命令式编程是第一人称，我要做什么，我要怎么做。 操作系统最喜欢这种编程范式了， 操作系统几乎不用"思考", 只要一对一的将代码翻译成指令就可以了。 而声明式编程则类似于"第二人称"， 也就是你要做什么。 有点"产品经理"和"开发“之间的关系， "产品经理"只负责提需求，而"开发"怎么实现他不并关心。 用户相对Kubernetes就是"产品经理"的角色， 用户只需要给Kubernetes提需求就可以了，比如说你(Kubernetes)给我(用户)创建一个运行Mysql服务的Demployment，这个Deployment运行的Pod镜像是xxxx，运行参数是xxxxx，挂载的数据卷是xxxxx。。。。。 等等。 开发(Kubernetes)接受到这个需求后，看看需求是否合理(验证Deployment里面的参数是否正确)，然后就开始创建了。 等待创建成功后，就告诉"产品经理"(用户)Deployment创建成功。 在创建过程中，用户并没有(也不需要)关心服务是如何创建的。 这种操作方式就是声明式API。 对于Kubernetes来说，声明式API最大的难点就在于如何提一个正确的需求了。

springboot开发微服务框架一般使用springcloud全家桶，而整个项目都是容器化的，通过k8s进行编排，而k8s自己也有服务发现机制，所以我们也可以抛弃springcloud里的eureka，而直接使用k8s自己的服务。 # 添加组件 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-ribbon</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes-ribbon</artifactId> <version>0.3.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-kubernetes</artifactId> <version>0.3.0.RELEASE</version> </dependency> 注意点

先说缓存，合理使用缓存是优化中最常见的，将从数据库中查询出来的数据放入缓存中，下次使用时不必从数据库查询，而是直接从缓存中读取，避免频繁操作数据库，减轻数据库的压力，同时提高系统性能。 一级缓存 一级缓存是SqlSession级别的缓存。在操作数据库时需要构造sqlSession对象，在对象中有一个数据结构用于存储缓存数据。不同的sqlSession之间的缓存数据区域是互相不影响的。也就是他只能作用在同一个sqlSession中，不同的sqlSession中的缓存是互相不能读取的。 一级缓存的工作原理： 用户发起查询请求，查找某条数据，sqlSession先去缓存中查找，是否有该数据，如果有，读取； 如果没有，从数据库中查询，并将查询到的数据放入一级缓存区域，供下次查找使用。 但sqlSession执行commit，即增删改操作时会清空缓存。这么做的目的是避免脏读。 如果commit不清空缓存，会有以下场景：A查询了某商品库存为10件，并将10件库存的数据存入缓存中，之后被客户买走了10件，数据被delete了，但是下次查询这件商品时，并不从数据库中查询，而是从缓存中查询，就会出现错误。 既然有了一级缓存，那么为什么要提供二级缓存呢？ 二级缓存是mapper级别的缓存，多个SqlSession去操作同一个Mapper的sql语句，多个SqlSession可以共用二级缓存

Eigen是一个高层次的C ++库，有效支持线性代数，矩阵和矢量运算，数值分析及其相关的算法。Eigen是一个开源库，从3.1.1版本开始遵从MPL2许可。 为了将Matlab写的运动学程序转化为C++所编写的dll，需要用用到矩阵库Eigen，Eigen库是一个使用C++源码编写的矩阵库，基本上能满足计算中所需要用到的运算，下面介绍一些库的入门学习。 1.首先是关于固定大小矩阵，向量的定义，初始化 #include<iostream> #include<Eigen/Core> using namespace std; using namespace Eigen; //import most commen Eigen types int main(int, char *[]) { Matrix3fm3; //3X3单精度矩阵 m3<< 1, 2, 3, 4, 5, 6, 7, 8, 9; Matrix4fm4 = Matrix4f::Identity();//4X4单位矩阵（单精度） Vector4iv4(1, 2, 3, 4); //长度为4的整形向量 //输出结果 std::cout<< "m3\n" << m3 << "\nm4:\n" <<m4 << "\nv4:\n" << v4 << std::endl; getchar(); return0; } /*学习笔记*/ /

一、概念 docker是开源容器引擎，基于cgroup,namespace,unionFS等技术实现，对应用进行封装的虚拟化技术 什么是cgroup？ 对系统资源限制，创建容器的过程其实就是在创建进程，对资源的分配和维护使用cgroup来管理，包括cpu，内存，io等? 什么是namespace? 创建容器时，对容器来说就是一个全新的系统，容器内的文件系统要和宿主机文件系统隔离，网络空间隔离，用户权限隔离，这些隔离操作都是有namespace 来管理完成的 什么是unionFS? 联合文件系统，简单理解就是多个目录结构合并成一个，而各个目录结构本身物理位置并没有变化。 二、架构 1.C/S架构 组件: docker cli: docker客户端，用来管理docker，向docker发送指令的工具 docker engine: 拉取推送镜像，对容器操作相关的api的最上层封装，直接面向client image repository: 注册中信，存储镜像的地方 Containerd: 是一个守护进程，负责管理shim,向docker engine提供接口,使用UnixSocket通信，协议是grpc shim: 负责管理单个容器，启动一个容器，就会启动一个shim进程, containerd管理所有容器 runC: 运行一个容器。是基于OCI标准的一个容器技术实现