Browsed by
标签:Mac

补习系列-springboot项目基础搭建课

补习系列-springboot项目基础搭建课

閱讀本文約花費: 10 (分鐘)前言 springboot 最近火的不行,目前几乎已经是 spring 家族最耀眼的项目了。抛开微服务、技术社区这些推广因素不说,框架本身的确有非常多的优点。比如 更简化的配置,摒除了许多繁杂的xml配置(事实证明,越简单的东西越容易让人记住); 内置Servlet容器,不再依赖外部环境 大量的starter模块,随手拈来 支持热部署 作为一名老程序员来说,仍然需要保持一个积极学习的态度。哎,简单点说就是少点伤感,认清现实。你曾经引以为傲的某某EE 技术已经被颠覆了,赶紧换车道 ….. 废话不多说,以下内容主要讲的是怎么利用springboot 这个脚手架搭建一个最精简的项目。其中几个模块会非常实用,这包括结构、配置、日志、部署.. 一、基础结构 springboot 项目仍然是使用maven 进行初始化及构建,下面是一个典型的结构: 目录文件 说明 pom.xml 依赖文件 src/main/java 代码目录 src/main/resources 配置目录,包含application.properties、log4j2.xml src/main/build 定义构建文件目录 src/test/java 测试代码 src/test/resources 测试配置 大致看一下就行了,不了解maven的话,点击这里先学习入门,项目的构建工具是…

Read More Read More

https://daniel.haxx.se/about.html

https://daniel.haxx.se/about.html

閱讀本文約花費: 21 (分鐘)This is the story of my background. What I’ve done and how I ended up like this. Daniel Stenberg I was born and raised in Huddinge, a suburb south of Sweden’s capital Stockholm. I have two brothers and two sisters. 1985 – it begins I discovered the joy of computers for the first time sometime in the early 80s when Kjell, a friend of mine, and I entered data sets in Basic that we eagerly read in some of the first C64 magazines at his place and since then I’ve been hooked. Kjell owned a C64 before me so it was in his home I had my first experiences in the …

Read More Read More

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

閱讀本文約花費: 10 (分鐘)生产关系能否决定生产力?为什么这个社会需要管理?Kubernetes 是如此的成功,它的开源治理和技术架构是有着非常密切的关系的。 Tue Feb 6, 2018 | 3000 Words | 大约需要阅读 6 分钟 | | 康威定律(Conway’s Law) 随着信息技术的发展,以及现实的IT公司的成功,如Amazon、Netflix,以及云计算的普及,微服务的实践正在走向很多传统用户,然而,实施微服务的过程中,和DevOps的理念一样,人们发现并非仅仅是技术所能够解决的。还要涉及到组织架构。于是,伴随着微服务的发展,一位很少被人提及的科学家被推到了前端,也是被人忽视而尘封的科学家。 时间要拨回到1967年,Melvin Conway 以独特的视角观察到一个组织的组织结构会对其开发的系统有很大的影响。并撰写了“How Do Committees Invent” 这样一篇影响深远的论文,其中被人们广为知道的结论: 设计系统【这里也不仅仅是指信息系统】的组织,其产生的设计和架构等价于组织间的沟通结构。 该定律基于这样一个推理:为了能够让软件之间的模块相互作用,软件的撰写者们必须相互频繁的进行沟通,因此,系统的软件界面结构将会反映出打造此系统的组织的社会边界,要知道跨边界的沟通是比较困难的。Conway 定律的目的是试图说明这是蛮常见的社会学…

Read More Read More

领域模型浅析

领域模型浅析

閱讀本文約花費: 20 (分鐘)领域模型 最近taowen同学连续发起了两起关于贫血模型和领域模型的讨论,引起了大家的广泛热烈的讨论,但是讨论(或者说是争论)的结果到底 怎样,我想值得商榷。问题是大家对贫血模型和领域模型都有自己的看法,如果没有对此达到概念上的共识,那么讨论的结果应该可想而知,讨论的收获也是有的, 至少知道了分歧的存在。为了使问题具有确定性,我想从一个简单例子着手,用我对贫血模型和领域模型的概念来分别实现例子。至于我的理解对与否,大家可以做 评判,至少有个可以评判的标准在这。 一个例子 我要举的是一个银行转帐的例子,又是一个被用滥了的例子。但即使这个例子也不是自己想出来的,而是剽窃的<<POJOs in Action>>中的例子,原谅我可怜的想像力 。当钱从一个帐户转到另一个帐户时,转帐的金额不能超过第一个帐户的存款余额,余额总数不能变,钱只是从一个账户流向另一个帐户,因此它们必须在一个事务内完成,每次事务成功完成都要记录此次转帐事务,这是所有的规则。 贫血模型 我们首先用贫血模型来实现。所谓贫血模型就是模型对象之间存在完整的关联(可能存在多余的关联),但是对象除了get和set方外外几乎就没有其它的方 法,整个对象充当的就是一个数据容器,用C语言的话来说就是一个结构体,所有的业务方法都在一个无状态的Service类中实现,Service类仅…

Read More Read More

浏览器UserAgent的趣味史

浏览器UserAgent的趣味史

閱讀本文約花費: 14 (分鐘)最近在看《给产品经理讲技术》,其中有一段简要的提到了浏览器UserAgent的含义和作用。在最后作者暗示UserAgent的变迁是一段充满趣味性的历史,为了满足我的好(吃)奇(瓜)心理,我去深扒了一下。 结果不扒不知道,一扒吓一跳。今天就给大家分享一下这个陈年老瓜。 首先,我们先简要了解一下各大浏览器的出生日期: 大家先对这些浏览器的出生时间有一个概念,然后大家把板凳和西瓜拿好,让我们开始吧~ 一、第一个浏览器:Nexus 1989年,超级大神伯纳斯·李教授发明了万维网(World Wide Web,简称3W),然而大神并不满足于此,为了大家能更方便地访问万维网,大神大手一挥,推出了世界上第一款浏览器。 李大神寻思给它起个什么名字呢? 此时,李大神可能是懒虫上身,想也不想,要不就叫World Wide Web,跟大儿子(万维网)一个名字吧! 后来大神感觉交流起来不是很方便,经常不知道World Wide Web指的是谁,而且这么偷懒的行为有点对不起小儿子,于是把小儿子的名字改成了Nexus。 由于是浏览器的祖师爷,没有竞争对手,Nexus马上就流行了起来。 由于是最早的浏览器,Nexus只支持文字展示,还不支持图片展示,而这恰好给了竞争对手可乘之机,同时也是UserAgent的由来。 二、第一个带图的浏览器:Mosaic 1993年,伊利诺伊的NCS…

Read More Read More

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

程序员必读书单 1.0

程序员必读书单 1.0

閱讀本文約花費: 80 (分鐘)本文把程序员所需掌握的关键知识总结为三大类19个关键概念,然后给出了掌握每个关键概念所需的入门书籍,必读书籍,以及延伸阅读。旨在成为最好最全面的程序员必读书单。 前言 Reading makes a full man; conference a ready man; and writing an exact man. Francis Bacon 优秀的程序员应该具备两方面能力: 良好的 程序设计 能力: 掌握常用的数据结构和算法(例如链表,栈,堆,队列,排序和散列); 理解计算机科学的核心概念(例如计算机系统结构、操作系统、编译原理和计算机网络); 熟悉至少两门以上编程语言(例如 C++,Java,C#,和 Python); 专业的 软件开发 素养: 具备良好的编程实践,能够编写可测试(Testable),可扩展(Extensible),可维护(Maintainable)的代码; 把握客户需求,按时交付客户所需要的软件产品; 理解现代软件开发过程中的核心概念(例如面向对象程序设计,测试驱动开发,持续集成,和持续交付等等)。 和其它能力一样, 程序设计 能力和 软件开发 素养源自项目经验和书本知识。项目经验因人而异(来自不同领域的程序员,项目差异会很大);但书本知识是相通的…

Read More Read More

数学之美番外篇:平凡而又神奇的贝叶斯方法

数学之美番外篇:平凡而又神奇的贝叶斯方法

閱讀本文約花費: 63 (分鐘) 概率论只不过是把常识用数学公式表达了出来。 ——拉普拉斯 目录 0. 前言1. 历史    1.1 一个例子:自然语言的二义性    1.2 贝叶斯公式2. 拼写纠正3. 模型比较与贝叶斯奥卡姆剃刀    3.1 再访拼写纠正    3.2 模型比较理论(Model Comparasion)与贝叶斯奥卡姆剃刀(Bayesian Occam’s Razor)    3.3 最小描述长度原则    3.4 最优贝叶斯推理4. 无处不在的贝叶斯    4.1 中文分词    4.2 统计机器翻译    4.3 贝叶斯图像识别,Analysis by Synthesis       4.4 EM 算法与基于模型的聚类    4.5 最大似然与最小二乘5. 朴素贝叶斯方法(又名“愚蠢者的贝叶斯(idiot’s bayes)”)    5.1 垃圾邮件过滤器 &nbs…

Read More Read More

怎样花两年时间去面试一个人

怎样花两年时间去面试一个人

閱讀本文約花費: 41 (分鐘)Joel Spolsky曾经感叹:招聘难,难于上青天(此处笔者稍加演绎:))。他有两个辛辣但不乏洞察力的断言:真正的牛人也许一辈子就投大概4次简历,这些家伙一毕业就被好公司抢走了,并且他们的雇主会给他们不赖的待遇,所以他们也不想挪窝。(刚刚去世的Dennis Ritchie就是这样一个人)而“人才”市场上能找到的大多都不是什么人才。招到这帮人轻则费钱重则把你公司搞挂。 (当我把这篇文章给邹欣老师review的时候,他说了另外两点:1. 最好的人也许不投简历,就决定去哪里了。所以要在他们做决定前找到他们。2. 比较差的会投很多次简历,找不到工作的时间越多,投的简历越多,给整个pool 带来很多噪音,top10%的简历也许根本不算全部人的top10%。) 诚然,也许没有哪个行业像IT行业这样,无形资产占据公司的绝大多数资产。拒坊间传言比尔·盖茨就曾经说过类似这样的话:只要允许我带走100个人我可以再造一个微软。这话没搜到原版出处,但是从一个侧面反映了IT公司当中智力资产所占的比例之重。 所以一个自然的推论就是,招聘也许是一个公司决策当中最最重要的一个环节。Joel Spolsky把他在这方面的观察,体会和洞见集结成了一本小册子《Smart and Gets Things Done》,开篇就挑战“产品是公司成败的关键”这个传统观念,他认为创造最适合工程师生…

Read More Read More

面试不愁,给你一份SpringBoot常用注解

面试不愁,给你一份SpringBoot常用注解

閱讀本文約花費: 9 (分鐘)一、注解(annotations)列表 @SpringBootApplication: 包含了@ComponentScan、@Configuration和@EnableAutoConfiguration注解。其中@ComponentScan让spring Boot扫描到Configuration类并把它加入到程序上下文。 @Configuration 等同于spring的XML配置文件;使用Java代码可以检查类型安全。 @EnableAutoConfiguration 自动配置。 @ComponentScan 组件扫描,可自动发现和装配一些Bean。 @Component可配合CommandLineRunner使用,在程序启动后执行一些基础任务。 @RestController注解是@Controller和@ResponseBody的合集,表示这是个控制器bean,并且是将函数的返回值直 接填入HTTP响应体中,是REST风格的控制器。 @Autowired自动导入。 @PathVariable获取参数。 @JsonBackReference解决嵌套外链问题。 @RepositoryRestResourcepublic配合spring-boot-starter-data-rest使用。 二、注解(annotations)详解 @SpringBootA…

Read More Read More

常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?

常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?

閱讀本文約花費: 13 (分鐘)在工作中你一定经常听别人谈起什么“四层负载均衡”“七层负载均衡”,什么“二层转发”“三层路由”,那么你真正理解这些层次的含义吗? 网络分层的知识教科书上都有,但很多都是“泛泛而谈”,只有“学术价值”,于是就容易和实际应用“脱节”,造成的后果就是“似懂非懂”,真正用的时候往往会“一头雾水”。 所以,今天我就从 HTTP 应用的角度,帮你把这些模糊的概念弄清楚。 TCP/IP 网络分层模型 还是先从 TCP/IP 协议开始讲起,一是因为它非常经典,二是因为它是目前事实上的网络通信标准,研究它的实用价值最大。 TCP/IP 当初的设计者真的是非常聪明,创造性地提出了“分层”的概念,把复杂的网络通信划分出多个层次,再给每一个层次分配不同的职责,层次内只专心做自己的事情就好,用“分而治之”的思想把一个“大麻烦”拆分成了数个“小麻烦”,从而解决了网络通信的难题。 你应该对 TCP/IP 的协议栈有所了解吧,这里我再贴一下层次图。 TCP/IP 协议总共有四层,就像搭积木一样,每一层需要下层的支撑,同时又支撑着上层,任何一层被抽掉都可能会导致整个协议栈坍塌。 我们来仔细地看一下这个精巧的积木架构,注意它的层次顺序是“从下往上”数的,所以第一层就是最下面的一层。 第一层叫“链接层”(link layer),负责在以太网、WiFi 这样的底层网络上发送原始数据包,工作…

Read More Read More

四层和七层负载均衡的区别

四层和七层负载均衡的区别

閱讀本文約花費: 33 (分鐘)(一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址;三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址;四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器;七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器。   ② 所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡,就是通过发布三层的IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡,就是在四层的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的Web服务器分成两组,一组是中文语言的…

Read More Read More

负载均衡基础知识

负载均衡基础知识

閱讀本文約花費: 18 (分鐘)一、什么是负载均衡?  互联网早期,业务流量比较小并且业务逻辑比较简单,单台服务器便可以满足基本的需求;但随着互联网的发展,业务流量越来越大并且业务逻辑也越来越复杂,单台机器的性能问题以及单点问题凸显了出来,因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢?  早期的方法是使用DNS做负载,通过给客户端解析不同的IP地址,让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题,在做出调度策略改变以后,由于DNS各级节点的缓存并不会及时的在客户端生效,而且DNS负载的调度策略比较简单,无法满足业务需求,因此就出现了负载均衡。  客户端的流量首先会到达负载均衡服务器,由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面,同时负载均衡服务器也会对应用服务器做周期性的健康检查,当发现故障节点时便动态的将节点从应用服务器集群中剔除,以此来保证应用的高可用。  负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层,主要工作是转发,它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。  七层负载均衡工作在OSI模型的应用层,因为它需要解析应用层流量,所以七层负载均衡在接到客户端的流量以后,还需要一个完整的TCP/IP协议栈。…

Read More Read More

云计算术语(中英文对照)

云计算术语(中英文对照)

閱讀本文約花費: 7 (分鐘)以下搜集了一些在云计算中会比较常遇到的一些术语,提供中英对照信息: 1. 自由计算      free computing  2. 弹性可伸缩    elastic and scalable  3. 主机          host / instance  4. 硬盘          hard disk/ volume  5. 密钥          key  6. 公开密钥      public key  7. 映像          image / mapping  8. 负载均衡      load balancing  9. 对象存储      object storage  10. 弹性计算      elastic computing  11. 按秒计费   &nb…

Read More Read More

【权限系统设计】ACL, DAC, MAC, RBAC, ABAC 模型的不同应用场景

【权限系统设计】ACL, DAC, MAC, RBAC, ABAC 模型的不同应用场景

閱讀本文約花費: 8 (分鐘)ACL 访问控制列表 规定资源可以被哪些主体进行哪些操作 场景:部门隔离 适用资源:客户页面、人事页面 在ACL权限模型下,权限管理是围绕资源来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下: ACL配置表 资源: 客户页面 主体: 销售部(组) 操作:增删改查 主体: 王总(用户) 操作: 增删改查 资源: 人事页面 主体: 王总(组) 操作: 增删改查 注:主体可以是用户,也可以是组。 在维护性上,一般在粗粒度和相对静态的情况下,比较容易维护。 在细粒度情况下,比如将不同的客户视为不同的资源,1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的,那么就要对每种资源做相同的操作;如果权限配置是无规律的,那么ACL不妨也是一种恰当的解决方案。 在动态情况下,权限经常变动,每添加一名员工,都需要配置所有他需要访问的资源,这在频繁变动的大型系统里,也是很难维护的。 在一些情况下,ACL也可应用于细粒度场景,接下来将介绍两种ACL的拓展。 DAC 自主访问控制 规定资源可以被哪些主体进行哪些操作 同时,主体可以将资源、操作的权限,授予其他主体 场景:文件系统 适用资源:人事培训文档 DAC是ACL的一种实现,强调灵活性。纯粹的ACL,权限由中心管理员统一分配,缺乏灵活性。为了加强灵活性,在ACL的基础…

Read More Read More

Kubernetes 网络通讯模型解析

Kubernetes 网络通讯模型解析

閱讀本文約花費: 7 (分鐘)Kubernetes 基础架构 架构图 从架构图看到,一次外部访问请求,并不会直接请求到kubernetes中具体的某个集群或者某一个资源模块,是需要经过各模块资源间的调度来完成的。网络 继续剖析Kubernetes的网络,如上图我们可以发现Kubernetes存在3种网络:节点网络,Pod网络,Service网络,最后再加上Internet与Service之间的网络总共4种。 于是我们可以总结Kubernetes需要解决4种通信模式:     1.容器和容器之间的通信     2.Pod和Pod之间的通信     3.Pod和Service之间的通信     4.Internet和Service之间的通信 容器和容器之间的网络 每一个Pod管理着一个或多个container,而对于同一个Pod之间的容器之间共享一个网络命名空间,它们之间可以直接通过localhost进行访问通信,这里以docker作为容器为例,容器间正好采用了container模式,额外创建启动一个容器,而这个容器不会有自己的网卡以及配置IP地址,而是和一个指定的容器共享IP和端口; 在Kubernetes里面每一个Pod都有…

Read More Read More

Scroll Up