Browsed by
分类: Unix/Linux

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

k8s常用命令实操

k8s常用命令实操

閱讀本文約花費: 12 (分鐘)查看集群信息: [[email protected] pods]# kubectl cluster-infoKubernetes master is running at http://localhost:8080KubeDNS is running at http://localhost:8080/api/v1/proxy/namespaces/kube-system/services/kube-dns To further debug and diagnose cluster problems, use ‘kubectl cluster-info dump’. 查看更详细的可以用kubectl cluster-info dump 查看各组件状态 [[email protected] pods]# kubectl -s http://localhost:8080 get componentstatusesNAME                              STATUS           &n…

Read More Read More

云和虚拟化有何区别?[云计算]

云和虚拟化有何区别?[云计算]

閱讀本文約花費: 6 (分鐘)由于虚拟化和云的核心理念都是从抽象资源中创建可用的环境,所以很容易被混为一谈。虚拟化是一种技术,可让用户以单个物理硬件系统为基础,创建多个模拟环境或专用资源。而云是一种能够抽象、汇集和共享整个网络中的可扩展资源的 IT 环境。简而言之,虚拟化是一项技术,而云是一种环境。 人们创建云通常是为了进行云计算,也就是在系统中运行工作负载。  云基础架构可以包含各种裸机、虚拟化或容器软件,它们可用于抽象、汇集和共享整个网络中的可扩展资源,以此来创建云。稳定的操作系统(如 Linux®)是云计算的基础。这一层架构可让用户独立于公共、私有和混合环境之间。 如果您能访问内部网和/或互联网,则可以使用虚拟化来创建云,但这不是唯一的选择。  通过虚拟化,虚拟机监控程序会监控物理硬件,并抽象机器中各项资源,之后把这些资源提供给叫做虚拟机的虚拟环境。这些资源可以是原始处理能力、存储或基于云的应用,其中包含了部署所需的所有运行时代码和资源。 如果就此停止,则不能叫做云——这仅仅是虚拟化。  只有向中央池分配了虚拟资源,才能被称为“云”。增加一层管理软件后,即可管控将在云中使用的基础架构、平台、应用和数据。再增加一层自动化工具,用来替换或减少人工操作可重复指令和流程,从而为云提供自助服务组件。 如果您建立的 IT 系统满足以下条件,则说明您…

Read More Read More

Java微服务实践乱谈

Java微服务实践乱谈

閱讀本文約花費: 25 (分鐘)楔子 目前业界最流行的微服务架构正在或者已被各种规模的互联网公司广泛接受和认可,业已成为互联网开发人员必备技术。无论是互联网、云计算还是大数据,Java平台已成为全栈的生态体系,其重要性几乎不可替代。 这两年微服务作为一个非常新的技术,各种理论流派试图从不同的角度去阐述其概念和优势,我一开始是拒绝的,因为我没有”Duang“的一下想清楚。个人感性地认知是,姿势不对,纯靠意会。理性的看法则是,在思想上,那些布道师们并未达到一致。经过参考各家思想之后,得到了一些自己的领悟,我分享给大家。 微服务是什么? 微服务是一种细粒度(Fine-Grain)的SOA 个人认为,与其说微服务是一种技术,不如将其定义为一种架构,而架构则是“技”的实现与“术”的策略相辅相成。“术”的策略需要分析使用场景,进行合理地划分业务边界,实现“业以类聚”,然而“技”的实现则通过特定的技术在实现业务逻辑之时,更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性,达到“技以群分”的目的。 由此而论,我个人偏好将其定义为:“微服务是一种细粒度的SOA”。 这样定义的好处在于,没必要去重复地“抹黑”“单体应用”(Monolithic,也有人翻译成“巨石应用”),缘于SOA技术的衍化过程中早已提及。那么,细粒度更多的体现在“取其精华,去其糟粕”。 SOA又是什么? SOA = Serv…

Read More Read More

Coolshell:应该知道的Linux技巧

Coolshell:应该知道的Linux技巧

閱讀本文約花費: 14 (分鐘)这篇文章来源于Quroa的一个问答《What are some time-saving tips that every Linux user should know?》—— Linux用户有哪些应该知道的提高效率的技巧。我觉得挺好的,总结得比较好,把其转过来,并加了一些自己的理解。 首先,我想告诉大家,在Unix/Linux下,最有效率技巧的不是操作图形界面,而是命令行操作,因为命令行意味着自动化。如果你看过《你可能不知道的Shell》以及《28个Unix/Linux的命令行神器》你就会知道Linux有多强大,这个强大完全来自于命令行,于是,就算你不知道怎么去做一个环保主义的程序员,至少他们可以让你少熬点夜,从而有利于你的身体健康和性生活。下面是一个有点长的列表,正如作者所说,你并不需要知道所有的这些东西,但是如果你还在很沉重地在使用Linux的话,这些东西都值得你看一看。 (注:如果你想知道下面涉及到的命令的更多的用法,你一定要man一点。对于一些命令,你可以需要先yum或apt-get来安装一下,如果有什么问题,别忘了Google。如果你要Baidu的话,我仅代表这个地球上所有的生物包括微生物甚至细菌病毒和小强BS你到宇宙毁灭) 基础 学习 Bash 。你可以man bash来看看bash的东西,并不复杂也并不长。你用别的sh…

Read More Read More

《REWORK》摘录及感想

《REWORK》摘录及感想

閱讀本文約花費: 45 (分鐘) 读了《Rework》这本书好多遍,每次读都有不同的感想。但从来没有把这些感想记录下来,今天把《Rework》书中的一些章节做一些摘录,并把我的一些感想总结出来。供大家参考。这是一本平生以来让我中毒很深的书,也是一本让我思考得很多的书。希望看到这篇文章的人都能好好地读读这本书。这本书并不难读,是一本你可以一口气不中断就可以读完的书。 现实世界 “这在现实世界里面行不通”,当你向人们介绍一个新创意时,人们总是这么回答你。这个“现实世界”听起来如此令人沮丧,……只有人耳熟能详,习以为常的事情才会胜利,即使是这些事情已经漏洞百出陈腐低效。 揭开“现实世界”这个锅盖,你会发现居住在里的人都充斥着悲观主义和失望的情绪。更糟的是,他们想将别人拖进他们的坟墓。如果你是充满希望和野心的人,他们会试着说服你,你的想法是不可能的。他们会说你在浪费时间。 “现实世界”并不存在,那只是人的一个借口。只是某些人为了开脱 自己的无所作为,跟你一点关系也没有。 感想:我经常会向一同事和朋友提及一些我的想法,朋友同事们经常会回答我——这个事某某人,某某团队做过了,没成功。或是对我说,你做这个事的时候,要小心这个要小心那个。我觉得,这个时候是最考验我们的时候了,要有一个清醒的头脑去分析别人的话,别人真不代表自己。这个世界上大多数人都是比较保守的,大多数都对这个现实世界都有或多或少的恐…

Read More Read More

软件架构设计-五视图方法论

软件架构设计-五视图方法论

閱讀本文約花費: 12 (分鐘)在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的 ​​​在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么,更谈不上掌握了。事实上,也只有极少数人能成为或者被冠以“架构师”这样的title。为此,笔者总结了对架构的一些理解,希望能够补充很多初入门的人在这方面认识上的不足,纠正一些误解。高手和老鸟就直接跳过吧。 架构的分类 对于“架构”来讲,理论上划分了5种架构视图,分别是:逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字,大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下,便于大家理解,大家可以不必纠结概念和这些理论。 逻辑架构:逻辑架构关注的是功能,包含用户直接可见的功能,还有系统中隐含的功能。或者更加通俗来描述,逻辑架构更偏向我们日常所理解的“分层”,把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。 开发架构:开发架构则更关注程序包,不仅仅是我们自己写的程序,还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台,以及主流的基于数据库的应用,都会比较关注。和逻辑架构有紧密的关联。 运…

Read More Read More

Spring源码笔记之Bean加载之准备创建Bean

Spring源码笔记之Bean加载之准备创建Bean

閱讀本文約花費: 16 (分鐘)我们知道从spring容器中获取单例bean时会先从缓存尝试获取,如果缓存中不存在已经加载的单例bean就需要从头开始bean的创建,而bean的创建过程是非常复杂的,本文就开始研究bean加载这部分的源码。 1. bean创建流程分析   在Spring中bean加载的逻辑是在getSingleton的重载方法中实现的: public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) { Assert.notNull(beanName, “‘beanName’ must not be null”); // 全局变量需要同步 synchronized (this.singletonObjects) { // 首先检查对应的bean是否已经加载过,因为singleton模式就是复用已创建的bean,所以这一步是必须的 Object singletonObject = this.singletonObjects.get(beanName); // 如果为空才可以进行singleton的bean的初始化 if (singletonObject == null) { if (this.singletonsCurrentlyInDestruction) {…

Read More Read More

CSRF的几种防御方法的利弊分析

CSRF的几种防御方法的利弊分析

閱讀本文約花費: 5 (分鐘)本文直接从防御方式开始讨论,防御CSRF有4种方法: 使用POST替代GET 检验HTTP Referer 验证码 Token 使用POST替代GET 一些程序员在开发的时候都是用GET、POST通用的函数来接收客户端的数据,这样也是某些接口有CSRF的原因之一,但是将全部接口都改成只允许POST方式访问,就能防范CSRF了吗?答案是:不能。只能说提高了一些成本。 原本是GET方式访问的接口,攻击者只需要构造接口的URL参数让受害者点击即可。现在改成使用POST方式访问,攻击者只需要利用其他站点,在站点上布置一个POST请求,让用户点击。 检验HTTP Referer HTTP Referer真是一个用于安全的字段,除了能防范CSRF,还能防JSONP劫持、盗链、站外提交等安全问题。但是HTTP Referer就一点问题都没有了吗?答案是:否定的,HTTP Referer只能检查点击的链接来源是来自站内还是站外,如果是GET方式的CSRF,那链接本身就是站内的,也就意味着检验HTTP Referer是无效的。 验证码 上面说的两种防御CSRF的方式,都有一定缺陷。但是使用验证码是完全可以做到防止CSRF的,因为验证码是用户在提交表单的时候,必须输入图片验证码,保证了服务器收到的是来自预期的请求。这里我补充一下,验证码功能必须没有缺陷才行,我之前测试过很…

Read More Read More

不同数据一致性模型有哪些应用?

不同数据一致性模型有哪些应用?

閱讀本文約花費: 11 (分鐘) 对于 CAP 来说,放弃强一致性(这里说的一致性是强一致性),追求分区容错性和可用性,这是很多分布式系统设计时的选择。在工程实践中,基于 CAP 定理逐步演化,就提出了 Base 理论。 那么 Base 理论有哪些内容,Base 理论下的一致性模型又有哪些呢? Base 理论 Base 是三个短语的简写,即基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)。 Base 理论的核心思想是最终一致性,即使无法做到强一致性(Strong Consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual Consistency)。 接下来我们着重对 Base 理论中的三要素进行讲解。 三个要素详解 基本可用 基本可用比较好理解,就是不追求 CAP 中的「任何时候,读写都是成功的」,而是系统能够基本运行,一直提供服务。基本可用强调了分布式系统在出现不可预知故障的时候,允许损失部分可用性,相比正常的系统,可能是响应时间延长,或者是服务被降级。 举个例子,在双十一秒杀活动中,如果抢购人数太多超过了系统的 QPS 峰值,可能会排队或者提示限流,这就是通过合理的手段保护系统的稳定性,保证主要的服务正常,保证基本可用。 软状态 …

Read More Read More

Kubernetes(K8s) 安装(使用kubeadm安装Kubernetes集群)

Kubernetes(K8s) 安装(使用kubeadm安装Kubernetes集群)

閱讀本文約花費: 18 (分鐘)概述:         这篇文章是为了介绍使用kubeadm安装Kubernetes集群(可以用于生产级别)。使用了Centos 7系统。 一、Centos7 配置说明 1.1   Firewalld(防火墙) CentOS Linux 7 默认开起来防火墙服务(firewalld),而Kubernetes的Master与工作Node之间会有大量的网络通信,安全的做法是在防火墙上配置Kbernetes各组件(api-server、kubelet等等)需要相互通信的端口号。在安全的内部网络环境中可以关闭防火墙服务。 关闭防火墙的命令: 1 # firewall-cmd –state #查看防火墙状态 2 # systemctl stop firewalld.service #停止firewall 3 # systemctl disable firewalld.service #禁止firewall开机启动 1.2   SELinux 建议禁用SELinux,让容器可以读取主机文件系统 执行命令: 1 # getenforce #查看selinux状态 2 # setenforce 0 #临时关闭selinux 3 # sed -i ‘s/^ *SELINUX=enforc…

Read More Read More

分布式系统中最基础的 CAP 理论及其应用

分布式系统中最基础的 CAP 理论及其应用

閱讀本文約花費: 10 (分鐘) 我们主要介绍分布式系统中最基础的 CAP 理论及其应用。 对于开发或设计分布式系统的架构师、工程师来说,CAP 是必须要掌握的基础理论,CAP 理论可以帮助架构师对系统设计中目标进行取舍,合理的规划系统拆分的维度。下面我们先讲讲分布式系统的特点。 分布式系统的特点 随着移动互联网的快速发展,互联网的用户数量越来越多,产生的数据规模也越来越大,对应用系统提出了更高的要求,我们的系统必须支持高并发访问和海量数据处理。 分布式系统技术就是用来解决集中式架构的性能瓶颈问题,来适应快速发展的业务规模,一般来说,分布式系统是建立在网络之上的硬件或者软件系统,彼此之间通过消息等方式进行通信和协调。 分布式系统的核心是可扩展性,通过对服务、存储的扩展,来提高系统的处理能力,通过对多台服务器协同工作,来完成单台服务器无法处理的任务,尤其是高并发或者大数据量的任务。 除了对可扩展性的需求,分布式系统还有不出现单点故障、服务或者存储无状态等特点。 单点故障(Single Point Failure)是指在系统中某个组件一旦失效,这会让整个系统无法工作,而不出现单点故障,单点不影响整体,就是分布式系统的设计目标之一; 无状态,是因为无状态的服务才能满足部分机器宕机不影响全部,可以随时进行扩展的需求。 由于分布式系统的特点,在分布式环境中更容易出现问题,比如节点之间通信失败…

Read More Read More

如何成为优秀的技术主管?你要做到这三点

如何成为优秀的技术主管?你要做到这三点

閱讀本文約花費: 36 (分鐘) 技术主管,又叫「技术经理」,英文一般是 Tech Leader ,简称 TL。随着工作经验的不断积累,能力的不断提升,每个人都有机会成为Team Leader。然而在机会到来前,我们必须提前做好准备,对TL的工作职责有一定了解。当然,这也会为当下更好地配合TL工作打下基础。 今天, 结合自己多年的经验,从开发规范、开发流程、技术规划与管理三个角度出发,分享对技术TL这一角色的理解与思考。 「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责,另外也会像一个程序员一样去开发实现系统。 一个技术主管的 60% ~ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上,而余下的 30% ~ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是,技术主管的大部分管理工作都是针对具体研发任务和技术事务的。 接下来基于我在技术TL这个角色上,在开发规范、开发流程、技术管理与规划等方面我的一些心路历程,和大家共勉。 开发规范 我当时负责的业务是集团收购一家子公司的业务,在整体技术标规范上与集团的技术标准存在很大的差异。开发规范可以说是我来到这个团队干的第一件事,我当时面对的问题是API接口格式混乱,没有标准的RPC服…

Read More Read More

Etcd Raft使用入门及原理解析

Etcd Raft使用入门及原理解析

閱讀本文約花費: 13 (分鐘)什么是Raft Raft是一个分布式一致性算法,充分的利用了可复制状态机以及日志。其最核心的设计目标就是易于理解。在性能、错误容错等方面来看有点类似Paxos,但不同之处在于,Raft论文较为清晰的描述了其主要流程以及其中一些细节问题,而Paxos我们知道非常难以理解。 当构建一个分布式系统时,一个非常重要的设计目标就是fault tolerance。如果系统基于Raft协议实现,那么当其中一个节点挂掉,或者发生了网络分区等异常情况时,只要大多数节点仍然能够正常通讯,整个集群就能够正常对外提供服务而不会挂掉。 关于Raft更多的细节,这里建议直接阅读论文: “In Search of an Understandable Consensus Algorithm“ 介绍 Etcd的Raft库已经在生产环境得到了非常广泛的应用,有力的支撑了etcd、K8S、Docker Swarm、TiDB/TiKV等分布式系统的构建,当你能够熟练的使用一个成熟的Raft库、甚至如果能够自己实现一个,那会有种’有了锤子,干什么都是钉子’的感觉。 特性 Etcd raft基本上已经实现了Raft协议的完整特性,包括: – Leader选举 – 日志复制 – 日志压缩 – 成员变更…

Read More Read More

如何以非root用户运行Docker容器

如何以非root用户运行Docker容器

閱讀本文約花費: 5 (分鐘)需要用root用户运行Docker? 组织中,经常以Root用户运行Docker中的容器。但是你的工作负载真的需要root权限吗?显然很少。尽管如此,默认情况下,你的容器仍将以root用户身份运行,但这可能会带来严重的安全问题。实际上,如果以root用户运行容器内部的进程,就是以root用户身份运行主机的进程。这就为那些恶意访问主机的攻击者,提供了机会。 只需在常用的任何镜像上使用以下命令,你就可以自己查看它使用的用户身份, 显然,作为最佳实践,我们应该避免以超级用户身份运行容器。因此,让我们看看如何以非root用户身份运行容器。 将非root用户添加到Dockerfile 你可以在Dockerfile中使用RUN命令创建用户,这个用户仅具有容器内工作负载所需的权限。 上面的命令行创建了一个用户newuser, 并指定了用户登录后使用的主目录和shell 。如下所示,将用户添加到你的Dockerfile中: 从第5行开始,每个命令都是以newuser身份而不是root身份运行。是不是很简单? 但是,我们并不总是仅使用自定义镜像。我们还使用了许多第三方镜像,因此我们无法像上面那样将root权限的用户注入其中。 这些第三方Docker镜像默认情况下将以root用户身份运行,除非我们对其进行处理。如果你使用不知名来源中的镜像,那么该镜像很可能嵌入了恶意命令,…

Read More Read More

Scroll Up