diff options
| author | zhaohuabing <zhaohuabing@gmail.com> | 2022-01-11 05:37:07 +0300 |
|---|---|---|
| committer | zhaohuabing <zhaohuabing@gmail.com> | 2022-01-11 05:37:07 +0300 |
| commit | a431e5009ebd8114c6d12a37985f646470537e58 (patch) | |
| tree | 8068dea2191f64db620c35b1e841c930e986e219 | |
| parent | a7efbc15f1c2a9eb97927ec7dfa1506156af6c68 (diff) | |
update image src
Signed-off-by: zhaohuabing <zhaohuabing@gmail.com>
20 files changed, 113 insertions, 113 deletions
diff --git a/exampleSite/content/post/2017-11-04-istio-install_and_example.md b/exampleSite/content/post/2017-11-04-istio-install_and_example.md index b167a5a..f6eb3e0 100644 --- a/exampleSite/content/post/2017-11-04-istio-install_and_example.md +++ b/exampleSite/content/post/2017-11-04-istio-install_and_example.md @@ -6,7 +6,7 @@ description: "Istio是来自Google，IBM和Lyft的一个Service Mesh（服务网 excerpt: "Istio是来自Google，IBM和Lyft的一个Service Mesh（服务网格）开源项目，是Google继Kubernetes之后的又一大作,本文将演示如何从裸机开始从零搭建Istio及Bookinfo示例程序。" date: 2017-11-04T12:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/istio-install_and_example/post-bg.jpg" +image: "/img/istio-install_and_example/post-bg.jpg" tags: - Istio URL: "/2017/11/04/istio-install_and_example/" @@ -21,13 +21,13 @@ categories: [ Tech ] <!--more--> 让我们来回顾一下微服务架构的发展过程。在出现服务网格之前，我们在微服务应用程序进程内处理服务通讯逻辑，包括服务发现，熔断，重试，超时等逻辑，如下图所示： - + 通过对这部分负责服务通讯的逻辑进行抽象和归纳，可以形成一个代码库供应用程序调用。但应用程序还是需要处理和各种语言代码库的调用细节，并且各种代码库互不兼容，导致对应用程序使用的语言和代码框架有较大限制。 如果我们更进一步，将这部分逻辑从应用程序进程中抽取出来，作为一个单独的进程进行部署，并将其作为服务间的通信代理，如下图所示： - + 因为通讯代理进程和应用进程一起部署，因此形象地把这种部署方式称为“sidecar”（三轮摩托的挎斗）。 - + 应用间的所有流量都需要经过代理，由于代理以sidecar方式和应用部署在同一台主机上，应用和代理之间的通讯被认为是可靠的。然后由代理来负责找到目的服务并负责通讯的可靠性和安全等问题。 当服务大量部署时，随着服务部署的sidecar代理之间的连接形成了一个如下图所示的网格，被称之为Service Mesh（服务网格），从而得出如下的服务网格定义。 @@ -36,10 +36,10 @@ _服务网格是一个基础设施层，用于处理服务间通信。云原生 _William Morgan _[_WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?_](https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/)_ _ - + 了解了服务网格的基本概念，下一步介绍一下[Istio](https://istio.io/)。Istio是来自Google，IBM和Lyft的一个Service Mesh（服务网格）开源项目，是Google继Kubernetes之后的又一大作，Istio架构先进，设计合理，刚一宣布就获得了Linkerd，nginmesh等其他Service Mesh项目的合作以及Red hat/Pivotal/Weaveworks/Tigera/Datawire等的积极响应。 - + 可以设想，在不久的将来，微服务的标准基础设施将是采用kubernetes进行服务部署和集群管理，采用Istio处理服务通讯和治理，两者相辅相成，缺一不可。 ## 安装Kubernetes @@ -50,7 +50,7 @@ Istio在架构设计上支持各种服务部署平台，包括kubernetes，cloud 从Istio控制面Pilot的架构图可以看到各种部署平台可以通过插件方式集成到Istio中，为Istio提供服务注册和发现功能。 - + kubernetes集群的部署较为复杂，[Rancher](http://rancher.com)提供了kubernetes部署模板，通过一键式安装，可以大大简化kubernetes集群的安装部署过程。 @@ -80,11 +80,11 @@ sudo docker run -d --restart=always -p 8080:8080 rancher/server ### 登录Rancher管理界面，创建k8s集群 -Rancher 管理界面的缺省端口为8080，在浏览器中打开该界面，通过菜单Default->Manage Environment->Add Environment添加一个kubernetes集群。这里需要输入名称kubernetes，描述，然后选择kubernetes template，点击create，创建Kubernetes环境。 +Rancher 管理界面的缺省端口为8080，在浏览器中打开该界面，通过菜单Default->Manage Environment->Add Environment添加一个kubernetes集群。这里需要输入名称kubernetes，描述，然后选择kubernetes template，点击create，创建Kubernetes环境。 点击菜单切换到kubernetes Environment，然后点击右上方的Add a host，添加一台host到kubernetes集群中。注意添加到集群中的host上必须先安装好符合要求的docker版本。 -然后根据Rancher页面上的提示在host上执行脚本启动Rancher agent，以将host加入ranch cluster。注意脚本中包含了rancher server的地址，在host上必须可以ping通该地址。 +然后根据Rancher页面上的提示在host上执行脚本启动Rancher agent，以将host加入ranch cluster。注意脚本中包含了rancher server的地址，在host上必须可以ping通该地址。 host加入cluster后Rancher会在host上pull kubernetes的images并启动kubernetes相关服务，根据安装环境所在网络情况不同需要等待几分钟到几十分钟不等。 @@ -100,7 +100,7 @@ chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl ``` -登录Rancher管理界面, 将 All Environments->kubernetes->KUBERNETES->CLI create config 的内容拷贝到~/.kube/config 中，以配置Kubectl和kubernetes server的连接信息。 +登录Rancher管理界面, 将 All Environments->kubernetes->KUBERNETES->CLI create config 的内容拷贝到~/.kube/config 中，以配置Kubectl和kubernetes server的连接信息。 ## 安装Istio @@ -184,7 +184,7 @@ reviews 10.43.219.248 <none> 9080/TCP 6m 在浏览器中打开应用程序页面，地址为istio-ingress的External IP `http://10.12.25.116/productpage` - + ## 理解Istio Proxy实现原理 @@ -321,7 +321,7 @@ Chain ISTIO_REDIRECT (3 references) 多次刷新Bookinfo应用的productpage页面，我们会发现该页面中显示的Book Reviews有时候有带红星的评价信息，有时有带黑星的评价信息，有时只有文字评价信息。 这是因为Bookinfo应用程序部署了3个版本的Reviews服务，每个版本的返回结果不同，在没有设置路由规则时，缺省的路由会将请求随机路由到每个版本的服务上，如下图所示： - + 通过创建一条路由规则route-rule.yaml，将请求流量都引导到Reviews-v1服务上 @@ -346,7 +346,7 @@ istioctl create -f route-rule.yaml -n default ``` 再次打开productpage页面, 无论刷新多少次，显示的页面将始终是v1版本的输出，即不带星的评价内容。 - + 删除该路由规则 ``` @@ -383,7 +383,7 @@ kubectl apply -f istio-0.2.10/install/kubernetes/addons/zipkin.yaml 在浏览器中打开zipkin页面，可以追踪一个端到端调用经过了哪些服务，以及各个服务花费的时间等详细信息，如下图所示： `http://10.12.25.116:30001` - + ## 性能指标监控 @@ -417,7 +417,7 @@ kubectl apply -f istio-0.2.10/install/kubernetes/addons/grafana.yaml 首先在浏览器中打开Bookinfo的页面`http://10.12.25.116/productpage`，刷新几次，以制造一些性能指标数据。 然后打开grafana页面查看性能指标`http://10.12.25.116:30002/dashboard/db/istio-dashboard`，如下图所示： - + ## 参考 diff --git a/exampleSite/content/post/2017-11-07-istio-traffic-shifting.md b/exampleSite/content/post/2017-11-07-istio-traffic-shifting.md index e6db50b..1b8f76e 100644 --- a/exampleSite/content/post/2017-11-07-istio-traffic-shifting.md +++ b/exampleSite/content/post/2017-11-07-istio-traffic-shifting.md @@ -6,7 +6,7 @@ description: "本任务将演示如何将应用流量逐渐从旧版本的服务 excerpt: "本任务将演示如何将应用流量逐渐从旧版本的服务迁移到新版本。通过Istio，可以使用一系列不同权重的规则（10%，20%，··· 100%）将流量平缓地从旧版本服务迁移到新版本服务。" date: 2017-11-07 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/istio-traffic-shifting/crossroads.png" +image: "/img/istio-traffic-shifting/crossroads.png" categories: [ "Tech"] tags: - Istio diff --git a/exampleSite/content/post/2017-11-08-istio-canary-release.md b/exampleSite/content/post/2017-11-08-istio-canary-release.md index ac9af13..e6610be 100644 --- a/exampleSite/content/post/2017-11-08-istio-canary-release.md +++ b/exampleSite/content/post/2017-11-08-istio-canary-release.md @@ -5,7 +5,7 @@ description: "当应用上线以后，运维面临的一大挑战是如何能在 excerpt: "当应用上线以后，运维面临的一大挑战是如何能在不影响已上线业务的情况下进行升级。本文将介绍如何使用Istio实现应用的灰度发布（金丝雀发布）" date: 2017-11-08 15:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/istio-canary-release/canary_bg.jpg" +image: "/img/istio-canary-release/canary_bg.jpg" published: true tags: - Istio @@ -26,7 +26,7 @@ categories: [ "Tech" ] “金丝雀发布”的来源于矿工们用金丝雀对矿井进行空气测试的做法。以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。 下图中，左下方的少部分用户就被当作“金丝雀”来用于测试新上线的1.1版本。如果新版本出现问题，“金丝雀”们会报警，但不会影响其他用户业务的正常运行。 - + 灰度发布（金丝雀发布）的流程如下： @@ -46,7 +46,7 @@ Istio通过高度的抽象和良好的设计采用一致的方式解决了该问 备注：采用kubernetes的[滚动升级(rolling update)](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/)功能也可以实现不中断业务的应用升级,但滚动升级是通过逐渐使用新版本的服务来替换老版本服务的方式对应用进行升级，在滚动升级不能对应用的流量分发进行控制，因此无法采用受控地把生产流量逐渐导流到新版本服务中，也就无法控制服务升级对用户造成的影响。 采用Istio后，可以通过定制路由规则将特定的流量（如指定特征的用户）导入新版本服务中，在生产环境下进行测试，同时通过渐进受控地导入生产流量，可以最小化升级中出现的故障对用户的影响。并且在同时存在新老版本服务时，还可根据应用压力对不同版本的服务进行独立的缩扩容，非常灵活。采用Istio进行灰度发布的流程如下图所示： - + ## 操作步骤 下面采用Istion自带的BookinfoInfo示例程序来试验灰度发布的流程。 @@ -125,10 +125,10 @@ reviews-v1-1360980140-0zs9z 2/2 Running 0 2m 在浏览器中打开应用程序页面，地址为istio-ingress的External IP。由于V1版本的reviews服务并不会调用rating服务，因此可以看到Product 页面显示的是不带星级的评价信息。 `http://10.12.25.116/productpage` - + 此时系统中微服务的部署情况如下图所示（下面的示意图均忽略和本例关系不大的details和ratings服务）： - + ### 部署V2版本的reviews服务 在部署V2版本的reviews服务前，需要先创建一条缺省路由规则route-rule-default-reviews.yaml，将所有生产流量都导向V1版本，避免对线上用户的影响。 @@ -178,14 +178,14 @@ spec: kubectl apply -f <(istioctl kube-inject -f bookinfo-reviews-v2.yaml) ``` 此时系统中部署了V1和V2两个版本的reviews服务，但所有的业务流量都被规则reviews-default导向了V1，如下图所示： - + ### 将测试流量导入到V2版本的reviews服务 在进行模拟测试时，由于测试环境和生产环境的网络，服务器，操作系统等环境存在差异，很难完全模拟生产环境进行测试。为了减少环境因素的对测试结果的影响，我们希望能在生产环境中进行上线前的测试，但如果没有很好的隔离措施，可能会导致测试影响已上线的业务，对企业造成损失。 通过采用Istio的路由规则，可以在类生产环境中进行测试，又完全隔离了线上用户的生产流量和测试流量，最小化模拟测试对已上线业务的影响。如下图所示： - + 创建一条规则，将用户名为 test-user 的流量导入到V2 @@ -215,10 +215,10 @@ spec: istioctl create -f route-rule-test-reviews-v2.yaml -n default ``` 以test-user用户登录，可以看到V2版本带星级的评价页面。 - + 注销test-user，只能看到V1版本不带星级的评价页面。如下图所示： - + ### 将部分生产流量导入到V2版本的reviews服务 @@ -251,7 +251,7 @@ istioctl replace -f route-rule-default-reviews.yaml -n default ``` 此时系统部署如下图所示： - + ### 将所有生产流量导入到到V2版本的reviews服务 @@ -276,10 +276,10 @@ spec: istioctl replace -f route-rule-default-reviews.yaml -n default ``` 系统部署如下图所示： - + 此时不管以任何用户登录，都只能看到V2版本带星级的评价页面，如下图所示： - + > 备注：如果灰度发布的过程中新版本的服务出现问题，则可以通过修改路由规则，将流量重新导入到V1版本的服务中，将V2版本故障修复后再进行测试。 diff --git a/exampleSite/content/post/2017-11-28-access-application-from-outside.md b/exampleSite/content/post/2017-11-28-access-application-from-outside.md index 47c5bca..810ada5 100644 --- a/exampleSite/content/post/2017-11-28-access-application-from-outside.md +++ b/exampleSite/content/post/2017-11-28-access-application-from-outside.md @@ -27,7 +27,7 @@ categories: [ Tech ] Pod(容器组),英文中Pod是豆荚的意思，从名字的含义可以看出，Pod是一组有依赖关系的容器，Pod包含的容器都会运行在同一个host节点上，共享相同的volumes和network namespace空间。Kubernetes以Pod为基本操作单元，可以同时启动多个相同的pod用于failover或者load balance。 - + Pod的生命周期是短暂的，Kubernetes根据应用的配置，会对Pod进行创建，销毁，根据监控指标进行缩扩容。kubernetes在创建Pod时可以选择集群中的任何一台空闲的Host，因此其网络地址是不固定的。由于Pod的这一特点，一般不建议直接通过Pod的地址去访问应用。 @@ -35,7 +35,7 @@ Pod的生命周期是短暂的，Kubernetes根据应用的配置，会对Pod进 为了解决访问Pod不方便直接访问的问题，Kubernetes采用了Service的概念，Service是对后端提供服务的一组Pod的抽象，Service会绑定到一个固定的虚拟IP上，该虚拟IP只在Kubernetes Cluster中可见，但其实该IP并不对应一个虚拟或者物理设备，而只是IPtable中的规则，然后再通过IPtable将服务请求路由到后端的Pod中。通过这种方式，可以确保服务消费者可以稳定地访问Pod提供的服务，而不用关心Pod的创建、删除、迁移等变化以及如何用一组Pod来进行负载均衡。 Service的机制如下图所示，Kube-proxy监听kubernetes master增加和删除Service以及Endpoint的消息，对于每一个Service，kube proxy创建相应的iptables规则，将发送到Service Cluster IP的流量转发到Service后端提供服务的Pod的相应端口上。 - + >备注：虽然可以通过Service的Cluster IP和服务端口访问到后端Pod提供的服务，但该Cluster IP是Ping不通的，原因是Cluster IP只是iptable中的规则，并不对应到一个网络设备。 @@ -48,7 +48,7 @@ Service的类型(ServiceType)决定了Service如何对外提供服务，根据 > 注意：官方文档中说明了Kubernetes clusterIp的流量转发到后端Pod有Iptable和kube proxy两种方式。但对Nodeport如何转发流量却语焉不详。该图来自网络，从图来看是通过kube proxy转发的，我没有去研究过源码。欢迎了解的同学跟帖说明。 - + 下面是通过NodePort向外暴露服务的一个例子，注意可以指定一个nodePort，也可以不指定。在不指定的情况下，kubernetes会从可用的端口范围内自动分配一个随机端口。 @@ -159,7 +159,7 @@ $ neutron lb-member-list 但是如果客户端不在Openstack Neutron的私有子网上，则还需要在load balancer的VIP上关联一个floating IP，以使外部客户端可以连接到load balancer。 部署Load balancer后，应用的拓扑结构如下图所示（注：本图假设Kubernetes Cluster部署在Openstack私有云上）。 - + >备注：如果kubernetes环境在Public Cloud上，Loadbalancer类型的Service创建出的外部Load Balancer已经带有公网IP地址，是可以直接从外部网络进行访问的，不需要绑定floating IP这个步骤。例如在AWS上创建的Elastic Load Balancing (ELB)，有兴趣可以看一下这篇文章：[Expose Services on your AWS Quick Start Kubernetes cluster]( http://docs.heptio.com/content/tutorials/aws-qs-services-elb.html)。 @@ -167,12 +167,12 @@ $ neutron lb-member-list 通过设置Service类型提供的是四层Load Balancer，当只需要向外暴露一个服务的时候，可以直接采用这种方式。但在一个应用需要对外提供多个服务时，采用该方式会为每一个服务（IP+Port）都创建一个外部load balancer。如下图所示 - + 一般来说，同一个应用的多个服务/资源会放在同一个域名下，在这种情况下，创建多个Load balancer是完全没有必要的，反而带来了额外的开销和管理成本。直接将服务暴露给外部用户也会导致了前端和后端的耦合，影响了后端架构的灵活性，如果以后由于业务需求对服务进行调整会直接影响到客户端。可以通过使用Kubernetes Ingress进行L7 load balancing来解决该问题。 ## 采用Ingress作为七层load balancer 首先看一下引入Ingress后的应用拓扑示意图（注：本图假设Kubernetes Cluster部署在Openstack私有云上）。 - + 这里Ingress起到了七层负载均衡器和Http方向代理的作用，可以根据不同的url把入口流量分发到不同的后端Service。外部客户端只看到foo.bar.com这个服务器，屏蔽了内部多个Service的实现方式。采用这种方式，简化了客户端的访问，并增加了后端实现和部署的灵活性，可以在不影响客户端的情况下对后端的服务部署进行调整。 下面是Kubernetes Ingress配置文件的示例，在虚拟主机foot.bar.com下面定义了两个Path，其中/foo被分发到后端服务s1，/bar被分发到后端服务s2。 diff --git a/exampleSite/content/post/2018-02-03-authentication-and-authorization-of-microservice.md b/exampleSite/content/post/2018-02-03-authentication-and-authorization-of-microservice.md index ae773ce..804b310 100644 --- a/exampleSite/content/post/2018-02-03-authentication-and-authorization-of-microservice.md +++ b/exampleSite/content/post/2018-02-03-authentication-and-authorization-of-microservice.md @@ -6,7 +6,7 @@ description: "微服务架构的引入为软件应用带来了诸多好处：包 excerpt: "微服务架构的引入为软件应用带来了诸多好处：包括小开发团队，缩短开发周期，语言选择灵活性，增强服务伸缩能力等。与此同时，也引入了分布式系统的诸多复杂问题。其中一个挑战就是如何在微服务架构中实现一个灵活，安全，高效的认证和鉴权方案。本文将尝试就此问题进行一次比较完整的探讨。" date: 2018-02-03 12:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-02-03-authentication-and-authorization-of-microservice/AuthenticationTrack.jpeg" +image: "/img/2018-02-03-authentication-and-authorization-of-microservice/AuthenticationTrack.jpeg" published: true tags: - Microservice @@ -25,11 +25,11 @@ categories: [ Tech ] 用户登录时，应用的安全模块对用户身份进行验证，验证用户身份合法后，为该用户生成一个会话(Session)，并为该Session关联一个唯一的编号(Session Id)。Session是应用中的一小块内存结构，其中保存了登录用户的信息，如User name, Role, Permission等。服务器把该Session的Session Id返回给客户端，客户端将Session Id以cookie或者URL重写的方式记录下来，并在后续请求中发送给应用，这样应用在接收到客户端访问请求时可以使用Session Id验证用户身份，不用每次请求时都输入用户名和密码进行身份验证。 > 备注：为了避免Session Id被第三者截取和盗用，客户端和应用之前应使用TLS加密通信，session也会设置有过期时间。 - + <center>单体应用用户登录认证序列图</center> 客户端访问应用时，Session Id随着HTTP请求发送到应用，客户端请求一般会通过一个拦截器处理所有收到的客户端请求。拦截器首先判断Session Id是否存在，如果该Session Id存在，就知道该用户已经登录。然后再通过查询用户权限判断用户能否执行该此请求，以实现操作鉴权。 - + <center>单体应用用户操作鉴权序列图</center> ## 微服务认证和鉴权面临的问题 @@ -38,7 +38,7 @@ categories: [ Tech ] * 微服务应遵循单一职责原理，一个微服务只处理单一的业务逻辑。认证和鉴权的公共逻辑不应该放到微服务实现中。 * 为了充分利用微服务架构的好处，实现微服务的水平扩展(Scalability)和弹性(Resiliency),微服务最好是无状态的。因此不建议使用session这种有状态的方案。 * 微服务架构下的认证和鉴权涉及到场景更为复杂，涉及到用户访问微服务应用，第三方应用访问微服务应用，应用内多个微服务之间相互访问等多种场景，每种场景下的认证和鉴权方案都需要考虑到，以保证应用程序的安全性。 - + <center>微服务认证和鉴权涉及到的三种场景</center> ## 微服务认证和鉴权的技术方案 @@ -114,7 +114,7 @@ Authorization: Bearer mF_9.B5f-4.1JqM 2. 如果请求中没有Token，Token过期或者Token验证非法，则拒绝用户请求。 3. Security Service检查用户是否具有该操作权 4. 如果用户具有该操作权限，则把请求发送到后端的Business Service，否则拒绝用户请求 - + <center>采用API Gateway和Token实现微服务应用的单点登录</center> ### 用户权限控制 @@ -171,7 +171,7 @@ OAuth针对不同场景有不同的认证流程，一个典型的认证流程如 >``` - + <center>OAuth认证流程</center> diff --git a/exampleSite/content/post/2018-02-09-docker-without-sudo.md b/exampleSite/content/post/2018-02-09-docker-without-sudo.md index de26410..23f3fd0 100644 --- a/exampleSite/content/post/2018-02-09-docker-without-sudo.md +++ b/exampleSite/content/post/2018-02-09-docker-without-sudo.md @@ -6,7 +6,7 @@ description: "如何使用非root用户执行docker命令" excerpt: "如何使用非root用户执行docker命令" date: 2018-02-09 10:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/docker.jpg" +image: "/img/docker.jpg" published: true showtoc: false tags: diff --git a/exampleSite/content/post/2018-02-09-vim-tips.md b/exampleSite/content/post/2018-02-09-vim-tips.md index 58bcad2..b81871e 100644 --- a/exampleSite/content/post/2018-02-09-vim-tips.md +++ b/exampleSite/content/post/2018-02-09-vim-tips.md @@ -5,7 +5,7 @@ subtitle: "" description: "Vim Tips and tricks" date: 2018-02-09 11:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-02-09-vim-tips/matrix.jpg" +image: "/img/2018-02-09-vim-tips/matrix.jpg" published: true tags: - Tips @@ -15,7 +15,7 @@ categories: [ Tips ] --- ## vim graphical cheat sheet - + <!--more--> ## Vim Jumps diff --git a/exampleSite/content/post/2018-03-13-use-docker-behind-http-proxy.md b/exampleSite/content/post/2018-03-13-use-docker-behind-http-proxy.md index 54c9ba0..a2473ec 100644 --- a/exampleSite/content/post/2018-03-13-use-docker-behind-http-proxy.md +++ b/exampleSite/content/post/2018-03-13-use-docker-behind-http-proxy.md @@ -5,7 +5,7 @@ subtitle: "" description: "如何配置docker使用HTTP代理" date: 2018-03-13 18:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/docker.jpg" +image: "/img/docker.jpg" published: true tags: - Tips diff --git a/exampleSite/content/post/2018-03-29-what-is-service-mesh-and-istio.md b/exampleSite/content/post/2018-03-29-what-is-service-mesh-and-istio.md index c75a8ae..ffa5b2c 100644 --- a/exampleSite/content/post/2018-03-29-what-is-service-mesh-and-istio.md +++ b/exampleSite/content/post/2018-03-29-what-is-service-mesh-and-istio.md @@ -5,7 +5,7 @@ subtitle: "Service Mesh模式及Istio开源项目介绍" description: "作为一种架构模式，微服务将复杂系统切分为数十乃至上百个小服务，每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改，并带来了语言和框架选择灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。另一方面，当应用被拆分为多个微服务进程后，进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性,本文介绍了Service Mesh模式如何应对微服务架构的这些挑战，以及Service Mesh的明星开源项目Istio。" date: 2018-03-29 12:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/istio-install_and_example/post-bg.jpg" +image: "/img/istio-install_and_example/post-bg.jpg" published: true tags: - Microservice @@ -20,7 +20,7 @@ categories: [ Tech ] 另一方面，当应用被拆分为多个微服务进程后，进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性。 <!--more--> - + 该变化带来了分布式系统的一系列问题，例如： * 如何找到服务的提供方？ @@ -38,9 +38,9 @@ categories: [ Tech ] 这些问题涉及到成百上千个服务的通信、管理、部署、版本、安全、故障转移、策略执行、遥测和监控等，要解决这些微服务架构引入的问题并非易事。 让我们来回顾一下微服务架构的发展过程。在出现服务网格之前，我们最开始在微服务应用程序内理服务之间的通讯逻辑，包括服务发现，熔断，重试，超时，加密，限流等逻辑。 - + 在一个分布式系统中，这部分逻辑比较复杂，为了为微服务应用提供一个稳定、可靠的基础设施层，避免大家重复造轮子，并减少犯错的可能，一般会通过对这部分负责服务通讯的逻辑进行抽象和归纳，形成一个代码库供各个微服务应用程序使用，如下图所示： - + 公共的代码库减少了应用程序的开发和维护工作量，降低了由应用开发人员单独实现微服务通讯逻辑出现错误的机率，但还是存在下述问题： * 微服务通讯逻辑对应用开发人员并不透明，应用开发人员需要理解并正确使用代码 库，不能将其全部精力聚焦于业务逻辑。 * 需要针对不同的语言/框架开发不同的代码库，反过来会影响微服务应用开发语言 和框架的选择，影响技术选择的灵活性。 @@ -49,13 +49,13 @@ categories: [ Tech ] 可以将微服务之间的通讯基础设施层和TCP/IP协议栈进行类比。TCP/IP协议栈为操作系统中的所有应用提供基础通信服务，但TCP/IP协议栈和应用程序之间并没有紧密的耦合关系，应用只需要使用TCP/IP协议提供的底层通讯功能,并不关心TCP/IP协议的实现，如IP如何进行路由，TCP如何创建链接等。 同样地，微服务应用也不应该需要关注服务发现，Load balancing，Retries，Circuit Breaker等微服务之间通信的底层细节。如果将为微服务提供通信服务的这部分逻辑从应用程序进程中抽取出来，作为一个单独的进程进行部署，并将其作为服务间的通信代理，可以得到如下图所示的架构： - + 因为通讯代理进程伴随应用进程一起部署，因此形象地把这种部署方式称为“sidecar”/边车（即三轮摩托的挎斗）。 应用间的所有流量都需要经过代理，由于代理以sidecar方式和应用部署在同一台主机上，应用和代理之间的通讯可以被认为是可靠的。由代理来负责找到目的服务并负责通讯的可靠性和安全等问题。 当服务大量部署时，随着服务部署的sidecar代理之间的连接形成了一个如下图所示的网格，该网格成为了微服务的通讯基础设施层，承载了微服务之间的所有流量，被称之为Service Mesh（服务网格）。 - + _服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。 @@ -64,7 +64,7 @@ _William Morgan _[_WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?_ 服务网格中有数量众多的Sidecar代理，如果对每个代理分别进行设置，工作量将非常巨大。为了更方便地对服务网格中的代理进行统一集中控制，在服务网格上增加了控制面组件。 - + 这里我们可以类比SDN的概念，控制面就类似于SDN网管中的控制器，负责路由策略的指定和路由规则下发；数据面类似于SDN网络中交换机，负责数据包的转发。 @@ -76,7 +76,7 @@ Istio是一个Service Mesh开源项目，是Google继Kubernetes之后的又一 凭借kubernetes良好的架构设计及其强大的扩展性，Google围绕kubernetes打造一个生态系统。Kubernetes用于微服务的编排（编排是英文Orchestration的直译，用大白话说就是描述一组微服务之间的关联关系，并负责微服务的部署、终止、升级、缩扩容等）。其向下用CNI(容器网络接口），CRI（容器运行时接口）标准接口可以对接不同的网络和容器运行时实现，提供微服务运行的基础设施。向上则用Istio提供了微服务治理功能。 由下图可见，Istio补充了Kubernetes生态圈的重要一环，是Google的微服务版图里一个里程碑式的扩张。 - + Google借Istio的力量推动微服务治理的事实标准，对Google自身的产品Google Cloud有极其重大的意义。其他的云服务厂商，如Redhat，Pivotal，Nginx，Buoyant等看到大势所趋，也纷纷跟进，宣布自身产品和Istio进行集成，以避免自己被落下，丢失其中的市场机会。 @@ -86,7 +86,7 @@ Istio服务包括网格由数据面和控制面两部分。 * 数据面由一组智能代理（Envoy）组成，代理部署为边车，调解和控制微服务之间所有的网络通信。 * 控制面负责管理和配置代理来路由流量，以及在运行时执行策略。 - + ### Istio控制面 Istio控制面板包括3个组件:Pilot, Mixer和Istio-Auth。 @@ -98,7 +98,7 @@ Pilot维护了网格中的服务的标准模型，这个标准模型是独立于 除此以外，Pilo还定义了一套和数据面通信的标准API，API提供的接口内容包括服务发现 、负载均衡池和路由表的动态更新。通过该标准API将控制面和数据面进行了解耦，简化了设计并提升了跨平台的可移植性。基于该标准API已经实现了多种Sidecar代理和Istio的集成，除Istio目前集成的Envoy外，还可以和Linkerd, Nginmesh等第三方通信代理进行集成，也可以基于该API自己编写Sidecar实现。 Pilot还定义了一套DSL（Domain Specific Language）语言，DSL语言提供了面向业务的高层抽象，可以被运维人员理解和使用。运维人员使用该DSL定义流量规则并下发到Pilot，这些规则被Pilot翻译成数据面的配置，再通过标准API分发到Envoy实例，可以在运行期对微服务的流量进行控制和调整。 - + #### Mixer 在微服务应用中，通常需要部署一些基础的后端公共服务以用于支撑业务功能。这些基础设施包括策略类如访问控制，配额管理；以及遥测报告如APM，日志等。微服务应用和这些后端支撑系统之间一般是直接集成的，这导致了应用和基础设置之间的紧密耦合，如果因为运维原因需要对基础设置进行升级或者改动，则需要修改各个微服务的应用代码，反之亦然。 @@ -112,7 +112,7 @@ Mixer主要提供了三个核心功能： Mixer的架构如图所示: - + 首先，Sidecar会从每一次请求中收集相关信息，如请求的路径，时间，源IP，目地服务，tracing头，日志等，并请这些属性上报给Mixer。Mixer和后端服务之间是通过适配器进行连接的，Mixer将Sidecar上报的内容通过适配器发送给后端服务。 @@ -130,7 +130,7 @@ Istio支持双向SSL认证（Mutual SSL Authentication）和基于角色的访 ##### 认证 Istio提供了一个内部的CA(证书机构),该CA为每个服务颁发证书，提供服务间访问的双向SSL身份认证，并进行通信加密，其架构如下图所示： - + 其工作机制如下： 部署时： @@ -149,7 +149,7 @@ Istio提供了一个内部的CA(证书机构),该CA为每个服务颁发证书 ##### 鉴权 Istio“基于角色的访问控制”（RBAC）提供了命名空间，服务，方法三个不同大小粒度的服务访问权限控制。其架构如下图所示： - + 管理人员可以定制访问控制的安全策略，这些安全策略保存在Istio Config Store中。 Istio RBAC Engine从Config Store中获取安全策略，根据安全策略对客户端发起的请求进行判断，并返回鉴权结果（允许或者禁止）。 @@ -187,14 +187,14 @@ Istio服务管控包括下列的典型应用场景： 在微服务架构中，业务的调用链非常复杂，一个来自用户的请求可能涉及到几十个服务的协同处理。因此需要一个跟踪系统来记录和分析同一次请求在整个调用链上的相关事件，从而帮助研发和运维人员分析系统瓶颈，快速定位异常和优化调用链路。 Istio通过在Envoy代理上收集调用相关数据，实现了对应用无侵入的分布式调用跟踪分析。 Istio实现分布式调用追踪的原理如下图所示: - + Envoy收集一个端到端调用中的各个分段的数据，并将这些调用追踪信息发送给Mixer，Mixer Adapter 将追踪信息发送给相应的服务后端进行处理。整个调用追踪信息的生成流程不需要应用程序介入，因此不需要将分布式跟踪相关代码注入到应用程序中。 >注意：应用仍需要在进行出口调用时将收到的入口请求中tracing相关的header转发出去，传递给调用链中下一个边车进行处理。 #### 度量收集 Istio 实现度量收集的原理如下图所示: - + Envoy收集指标相关的原始数据，如请求的服务，HTTP状态码，调用时延等，这些收集到的指标数据被送到Mixer，通过Mixer Adapters 将指标信息转换后发送到后端的监控系统中。由于Mixer使用了插件机制，后端监控系统可以根据需要在运行期进行动态切换。 @@ -208,13 +208,13 @@ Istio通过高度的抽象和良好的设计采用一致的方式实现了灰度 采用Istio进行灰度发布的流程如下图所示： 首先，通过部署新版本的服务，并将通过路由规则将金丝雀用户的流量导入到新版本服务中 - + 测试稳定后，使用路由规则将生产流量逐渐导入到新版本系统中，如按5%，10%，50%，80%逐渐导入。 - + 如果新版本工作正常，则最后将所有流量导入到新版本服务中，并将老版本服务下线；如中间出现问题，则可以将流量重新导回老版本，在新版本中修复故障后采用该流程重新发布。 - + #### 断路器 在微服务架构中，存在着许许多多的服务单元，若一个服务出现故障，就会因依赖关系形成故障蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器模式。 @@ -222,11 +222,11 @@ Istio通过高度的抽象和良好的设计采用一致的方式实现了灰度 断路器模式指，在某个服务发生故障时，断路器的故障监控向调用放返回一个及时的错误响应，而不是长时间的等待。这样就不会使得调用线程因调用故障被长时间占用，从而避免了故障在整个系统中的蔓延。 Istio 实现断路器的原理如下图所示: - + 管理员通过destination policy设置断路触发条件，断路时间等参数。例如设置服务B发生10次5XX错误后断路15分钟。则当服务B的某一实例满足断路条件后，就会被从LB池中移除15分钟。在这段时间内，Envoy将不再把客户端的请求转发到该服务实例。 Istio的断路器还支持配置最大链接数，最大待处理请求数，最大请求数，每链接最大请求数，重试次数等参数。当达到设置的最大请求数后，新发起的请求会被Envoy直接拒绝。 - + #### 故障注入 对于一个大型微服务应用而言，系统的健壮性非常重要。在微服务系统中存在大量的服务实例，当部分服务实例出现问题时，微服务应用需要具有较高的容错性，通过重试，断路，自愈等手段保证系统能够继续对外正常提供服务。因此在应用发布到生产系统强需要对系统进行充分的健壮性测试。 @@ -236,7 +236,7 @@ Istio的断路器还支持配置最大链接数，最大待处理请求数，最 Istio通过服务网格承载了微服务之间的通信流量，因此可以在网格中通过规则进行故障注入，模拟部分微服务出现故障的情况，对整个应用的健壮性进行测试。 故障注入的原理如下图所示： - + 测试人员通过Pilot向Envoy注入了一个规则，为发向服务MS-B的请求加入了指定时间的延迟。当客户端请求发向MSB-B时，Envoy会根据该规则为该请求加入时延，引起客户的请求超时。通过设置规则注入故障的方式，测试人员可以很方便地模拟微服务之间的各种通信故障，对微服务应用的健壮性进行较为完整的模拟测试。 ## 总结 diff --git a/exampleSite/content/post/2018-04-11-service-mesh-vs-api-gateway.md b/exampleSite/content/post/2018-04-11-service-mesh-vs-api-gateway.md index 139a385..826f7b6 100644 --- a/exampleSite/content/post/2018-04-11-service-mesh-vs-api-gateway.md +++ b/exampleSite/content/post/2018-04-11-service-mesh-vs-api-gateway.md @@ -6,7 +6,7 @@ description: "API Gateway和Service Mesh的关系是我最近一直在思考的 excerpt: "API Gateway和Service Mesh的关系是我最近一直在思考的问题，也和同事及社区的朋友之间进行了一些讨论。这篇短文很清晰地总结了两者之间的相似之处以及这两者在微服务架构中的不同用途。" date: 2018-04-11 09:32:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-04-11-service-mesh-vs-api-gateway/background.jpg" +image: "/img/2018-04-11-service-mesh-vs-api-gateway/background.jpg" published: true tags: - Microservice @@ -52,7 +52,7 @@ API Gateway和Service Mesh之间的主要不同点：API Gateway是暴露API/边 图1： API Gateway和Service Mesh实践 - + 如上图所示，Service Mesh作为Sidecar（边车）和服务一起部署，它是独立于服务的业务逻辑的。 @@ -69,7 +69,7 @@ API Gateway和Service Mesh的关系是我最近一直在思考的问题，也和 API Gateway作为微服务引用的流量入口，其对效率要求较高，如果随API Gateway部署一个Sidecar，可能对效率有一定影响。 我对此未进行测试，但从理论上来说，服务发现，重试，断路等逻辑无论放到API Gateway还是Service Mesh中耗时应该是差不多的，部署Sidecar只是增加了创建一个本地链接的消耗，如下图所示: - + 将API Gateway和Service Mesh的功能进行清晰划分，API Gateway负责应用逻辑，Service Mesh负责服务通讯，Metrics收集等微服务基础设施，这样划分后在架构上更为清晰。对于效率问题，我们可以考虑对API Gateway进行水平扩展来解决。 diff --git a/exampleSite/content/post/2018-04-16-using-helm-to-deploy-to-kubernetes.md b/exampleSite/content/post/2018-04-16-using-helm-to-deploy-to-kubernetes.md index 320b465..09ba985 100644 --- a/exampleSite/content/post/2018-04-16-using-helm-to-deploy-to-kubernetes.md +++ b/exampleSite/content/post/2018-04-16-using-helm-to-deploy-to-kubernetes.md @@ -6,7 +6,7 @@ description: "Helm是Kubernetes生态系统中的一个软件包管理工具。 excerpt: "Helm是Kubernetes生态系统中的一个软件包管理工具。本文将介绍为何要使用Helm进行Kubernetes软件包管理，澄清Helm中使用到的相关概念，并通过一个具体的示例学习如何使用Helm打包，分发，安装，升级及回退Kubernetes应用。" date: 2018-04-16 15:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-04-16-using-helm-to-deploy-to-kubernetes/buffalo.jpg" +image: "/img/2018-04-16-using-helm-to-deploy-to-kubernetes/buffalo.jpg" published: true tags: - Kubernetes @@ -30,7 +30,7 @@ kubernetes的核心设计理念是: 用户定义应用程序的规格，而kuber 以下面的wordpress应用程序为例，涉及到多个kubernetes API对象，这些kubernetes API对象分散在多个yaml文件中。 图1： Wordpress应用程序中涉及到的kubernetes API对象 - + 可以看到，在进行kubernetes软件部署时，我们面临下述问题： @@ -81,7 +81,7 @@ Helm的引入很好地解决上面这些问题。 下面这张图描述了Helm的几个关键组件Helm（客户端），Tiller（服务器），Repository（Chart软件仓库），Chart（软件包）之前的关系。 图2： Helm软件架构 - + ## 安装Helm - - - @@ -335,7 +335,7 @@ Helm作为kubernetes应用的包管理以及部署工具，提供了应用打包 **A**: 采用Helm可以把零散的Kubernetes应用配置文件作为一个chart管理，chart源码可以和源代码一起放到git库中管理。Helm还简了在CI/CD pipeline的软件部署流程。通过把chart参数化，可以在测试环境和生产环境可以采用不同的chart参数配置。 下图是采用了Helm的一个CI/CD流程 - + **Q**: 感谢分享，请问下多环境(test,staging，production)的业务配置如何管理呢？通过heml打包configmap吗，比如配置文件更新，也要重新打chats包吗？谢谢，这块我比较乱<BR> **A**：Chart是支持参数替换的，可以把业务配置相关的参数设置为模板变量。使用Helm install Chart的时候可以指定一个参数值文件，这样就可以把业务参数从Chart中剥离了。例子： helm install --values=myvals.yaml wordpress diff --git a/exampleSite/content/post/2018-05-01-may-day-jiulonghu.md b/exampleSite/content/post/2018-05-01-may-day-jiulonghu.md index 57326c7..48cb0e1 100644 --- a/exampleSite/content/post/2018-05-01-may-day-jiulonghu.md +++ b/exampleSite/content/post/2018-05-01-may-day-jiulonghu.md @@ -4,7 +4,7 @@ title: "川西秘境探险" subtitle: "2018五一甘堡藏寨，九龙湖自驾游记" date: 2018-05-01 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-05-01-may-day-jiulonghu/snowmountain.jpg" +image: "/img/2018-05-01-may-day-jiulonghu/snowmountain.jpg" published: true hide-in-home: true tags: @@ -26,7 +26,7 @@ URL: "/2018/05/01/may-day-jiulonghu" “浮云牧场”走的是网红路线，马蜂窝，微信公众号的宣传做得好，知名度较高，房间比较紧俏，在五一期间更是一房难求，而且价格也比较感人。两位领导都持家有方，指示我们上去看看风景，然后下山再找住宿。 过了桃坪羌寨大概几公里，317国道右边有一个比较明显的指路牌，往右上山，就是到浮云牧场的路。我们兴冲冲地开车上了山，此时，我们心中向往的浮云牧场是这样子的（取图自网络）： - + 上山的路况还可以，但比较窄，回头弯较多，需要注意对方来车。开了将近1小时后，来到了半山腰，对面来了好几辆下山的车。由于两方相遇的路面较窄，开始堵车了。这时乘机向对方打听了山上的情况，得知酒店封路了，只有预定了房间的人才能进入浮云牧场。 得知这个消息，此时我们的内心是崩溃的，已经开了一大半的山路，现在却得知不能进去。没有办法，大家商量后还是决定下山。不过“塞翁失马，焉知非福”，这次没进入浮云牧场，为第二天探秘一个新景点埋下伏笔，现在暂时不表。于是我和朋友调转车头，悻悻下山，败意而回。 @@ -40,16 +40,16 @@ URL: "/2018/05/01/may-day-jiulonghu" 这是一个河边的小院，有三层楼，院子里面种满了各种植物和花卉，老板是个很和气的中年人，把小院收拾得很舒服。房间里挺宽敞，床上套着雪白的床单，非常干净整洁。 院子里的洋槐树树冠上开满了白色的小花，配着嫩绿的树叶和攀缘的蔷薇，感觉非常的清新和惬意。 - + 老板的三层小楼，这里的修房的材料不是砖头，而是就地取材用山上的片状岩石修砌而成的，很有特色。 - + 窗户旁边挂着金黄色的玉米。 - + 院子里种的玫瑰花。 - + 我们和老板闲聊，提到今天没得进到浮云牧场，老板笑道：这浮云牧场的景色我们这里到处都有，只是浮云牧场有老板投资，宣传做得好罢了。这后面山上就有草场，还有一个九龙湖，就挺好耍。我们听了，赶紧向老板仔细打听线路和路况，跃跃欲试，打算明天去探寻这个尚未开发的野景点。 @@ -60,69 +60,69 @@ URL: "/2018/05/01/may-day-jiulonghu" ## 甘堡藏寨风情 昨晚虽然睡得不是很熟，但藏家院子里空气清新，精神恢复得很快，我没到七点就醒了。起床和大家一起吃了早饭，早饭是烤馍，鸡蛋，咸菜和稀饭。吃完饭后，陪孩子们去寨子里逛了一下。寨子不大，半个小时就能走完，街上摆着一些小摊，售卖一些民族特色的小饰品。 - + 两个小朋友在小摊上找自己喜欢的小饰品，摊主是一个十八九岁的小姑娘，她平时在成都读书，放假回来摆个小摊勤工俭学。最后照顾她生意，给每个小朋友买了一个十多块钱的小玩意。 - + 寨子墙上的石板画，画的是藏族传说中的英雄人物格萨尔王。 - + ## 探秘九龙湖 我逛完寨子，其余人也收拾妥当了。向老板告辞后，我们准备向九龙湖进发。细心的老板怕我们找不到地方，特意给我们画了一张地图。 - + 开车顺着河边一路上山，很快就上了盘山公路。路面是水泥的，有护栏，只是路比较窄，很对地方只能容一车通过。川西山区的路基本都是这样之字形的，回头弯很多，这种回头弯一般有30到40度的坡度。我家的小狮子是1.6的，如果速度开慢点的话，过弯时得用一档。 - + 山路两边的风景很美，低海拔地区有很多樱桃树，核桃树以及开满了花的洋槐树。洋槐花蜜过一段时间就会上市了，很香的。我们摘了一些花带回家，杨槐花焯水后可以炒蛋，也可以和在面里面吃。 - + 树上结满了樱桃，别看樱桃树不高，一棵树可以产两百斤樱桃。 - + 再往上开，到了海拔高一点的地方，乔木就比较少了，路两边多是低矮的绿色灌木，以及不知名的小花。五月间的植物都是嫩绿嫩绿的，煞是好看。 - - + + 看到几头牛在路边吃草，看这淡定的眼神！山路边还时不时冒出一群小黑猪，目测就是一只就十多斤重，想给它们拍张照片，飞快地钻进灌木丛里面了，只好作罢。川西山里和草原上这种猪都是这样像牛羊一样放养的。我们流着口水说这个是资格的跑山猪，味道肯定巴适！ - + 半山上的几户藏家。 - + 开到最高的一个寨子后，后面的路就是土路了。向寨子里一个大姐打听了一下，大姐信誓旦旦地说这两天没下大雨，轿车开上去没问题，于是我们就继续往上开了。 上土路后不久，遇到一个搭车的老爷子，他要去山顶的寺庙烧香。我们的运气也挺好，要不是老人家陪我们一起，后面我们不一定找得到地方。 - + 开了一段土路后，发现路比较窄，路边就是悬崖，而且没有护栏。老婆娃儿都说还是停下来走路上去算了。于是和朋友找了一个路口把车停到路边，开始走路上山。朋友停车后说，在前面几个转弯的地方，开车时脚趾拇都抓紧了。 最后一段就是这种路，地面硬化程度不错，没有下雨的情况下，胆子大点的老师傅可以开上山。 - + 老爷子说这个路开车完全没得问题嘛，他看到别人都开车上去的。我们是不敢继续往前开了，他也只好下车和我们一起走。我一边走一边和老人家聊天，得知他已经高寿76了，完全看不出来，腰板硬朗，牙齿健全，走路比我们年轻人还快。老人家自豪地说他寨子阳光好，地肥沃，种什么粮食产量都高。 老人家所在的寨子，地里面已经种上了玉米。 - + 我继续和老爷子边走边聊，老爷子告诉我，走山路要不紧不慢，快了容易呼吸不畅，引起高原反应。还给我介绍路边的各种植物，哪种可以食用。从聊天中得知，大爷姓何，祖上是从陕西迁移到这里的，到他这里已经是第九代了。家里有四个女儿，都在理县做生意或者打工，寨子的家里就他和老伴。他说他喜欢住在山里，一年也出不了几次山。 看得出老爷子很高兴有人能陪他说说话，住在山里虽然空气好，但子女不在身边，老人平时估计也比较寂寞。 老爷子说这种野菜煮汤喝很香。 - + 转过一个弯，听见路边的灌木丛中“噗噗”的声音，飞出一只长尾巴的大鸟来，老爷子说那是野鸡。太快了没能拍到照片。 就这么慢慢地走了将近1小时，来到了山顶上。 令人惊奇的是，虽然上山的路很陡，但山顶上却非常开阔，有一大片草坝子。从山顶上可以隐约看到对面巍峨的雪山，今天天气不是很好，能见度不高，如果是在晴天的话，肯定非常壮观。 - + 山顶搭建了一个台子和一个草房。大爷说这是举行节日的时候的临时厨房。每年有三个时间山顶的草坝上会举行锅庄舞会。这个木板上标注了山顶上望过去的几座雪山，可以看到最高的大黄峰有将近6000米高。 - + 山顶还有一个小秋千，两个小孩在上面玩得不亦乐乎。 - + 我对比了网上浮云牧场的图片，感觉这个山顶的雪山比浮云牧场更雄伟。这座山的风景也更好，树木，灌木，草地层次分明；而浮云牧场上山的路上很多地方是光秃秃的。 diff --git a/exampleSite/content/post/2018-05-21-algolia-integration-with-jekyll.md b/exampleSite/content/post/2018-05-21-algolia-integration-with-jekyll.md index 56473ec..cbe0df7 100644 --- a/exampleSite/content/post/2018-05-21-algolia-integration-with-jekyll.md +++ b/exampleSite/content/post/2018-05-21-algolia-integration-with-jekyll.md @@ -4,7 +4,7 @@ title: "使用Algolia为Gitpage博客提供站内搜索" subtitle: "" date: 2018-05-21 11:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-05-06-cryptocurrency_week1/bitcoin_header.jpg" +image: "/img/2018-05-06-cryptocurrency_week1/bitcoin_header.jpg" published: false tags: - Jekyll:q @@ -24,7 +24,7 @@ URL: "/2018/05/21/algolia-integration-with-jekyll" ## Scrooge Coin Transaction Scrooge Coin programming assignment is a little bit tricky, the video of this lesson hasn't explained some implementation details. To help you understand the transaction data structure used in Scrooge Coin, I draw this diagram: - + <!--more--> Every transaction has a set of inputs and a set of outputs. An input in a transaction must use a hash pointer to refer to its corresponding output in the previous transaction, and it must be signed with the private key of the owner because the owner needs to prove he/she agrees to spend his/her coins. diff --git a/exampleSite/content/post/2018-05-22-user_authentication_authorization.md b/exampleSite/content/post/2018-05-22-user_authentication_authorization.md index dd809ad..810d96a 100644 --- a/exampleSite/content/post/2018-05-22-user_authentication_authorization.md +++ b/exampleSite/content/post/2018-05-22-user_authentication_authorization.md @@ -6,7 +6,7 @@ description: "这段时间对之前微服务安全相关的一些想法进行了 excerpt: "这段时间对之前微服务安全相关的一些想法进行了进一步总结和归纳，理清在之前文章里面没有想得太清楚的地方，例如服务间的认证与鉴权以及用户身份在服务调用链中的传递。在这一系列博客里面将分为三个部分对微服务安全进行系统阐述：用户访问认证与鉴权，服务间认证与鉴权，外部系统访问控制。" date: 2018-05-23T10:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-05-22-user_authentication_authorization/background.jpg" +image: "/img/2018-05-22-user_authentication_authorization/background.jpg" published: true tags: - Microservice @@ -30,7 +30,7 @@ categories: [ "Tech" ] 微服务架构的引入为软件应用带来了诸多好处：包括小开发团队，缩短开发周期，语言选择灵活性，增强服务伸缩能力等。与此同时，也引入了分布式系统的诸多复杂问题。其中一个挑战就是如何在微服务架构中实现一个灵活，安全，高效的认证和鉴权方案。 相对于传统单体应用，微服务架构下的认证和鉴权涉及到场景更为复杂，涉及到用户访问微服务应用，第三方应用访问微服务应用，应用内多个微服务之间相互访问等多种场景，每种场景下的认证和鉴权方案都需要考虑到，以保证应用程序的安全性。本系列博文将就此问题进行一次比较完整的探讨。 - + <center>微服务认证和鉴权涉及到的三种场景</center> ## 用户认证和鉴权 @@ -111,7 +111,7 @@ Authorization: Bearer mF_9.B5f-4.1JqM 2. 如果请求中没有Token，Token过期或者Token验证非法，则拒绝用户请求。 3. Security Service检查用户是否具有该操作权(可选，参见下一小节) 4. 如果用户具有该操作权限，则把请求发送到后端的Business Service，否则拒绝用户请求 - + <center>采用API Gateway和Token实现微服务应用的单点登录</center> ### 用户权限控制 diff --git a/exampleSite/content/post/2018-05-23-external_system_auth.md b/exampleSite/content/post/2018-05-23-external_system_auth.md index c4fddd8..fa31300 100644 --- a/exampleSite/content/post/2018-05-23-external_system_auth.md +++ b/exampleSite/content/post/2018-05-23-external_system_auth.md @@ -6,7 +6,7 @@ description: "一些外部的第三方系统可能需要访问系统内部的微 excerpt: "一些外部的第三方系统也可能需要访问系统内部的微服务。例如在网上商店的例子中，外部的推荐服务可能需要接入系统，以获取商店的商品目录信息。相对于内部服务之间的访问而言，外部系统的访问需要进行严格的安全控制。" date: 2018-05-23T18:00:00 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-05-23-external_system_auth/background.jpg" +image: "/img/2018-05-23-external_system_auth/background.jpg" published: true tags: - Microservice @@ -70,7 +70,7 @@ OAuth针对不同场景有不同的认证流程，一个典型的认证流程如 >``` - + <center>OAuth认证流程</center> diff --git a/exampleSite/content/post/2018-05-23-istio-auto-injection-with-webhook.md b/exampleSite/content/post/2018-05-23-istio-auto-injection-with-webhook.md index 4baf9e6..fd0ab71 100644 --- a/exampleSite/content/post/2018-05-23-istio-auto-injection-with-webhook.md +++ b/exampleSite/content/post/2018-05-23-istio-auto-injection-with-webhook.md @@ -7,7 +7,7 @@ description: "Kubernets 1.9版本引入了Admission Webhook(web 回调)扩展机 excerpt: "Kubernets 1.9版本引入了Admission Webhook(web 回调)扩展机制，通过Webhook,开发者可以非常灵活地对Kubernets API Server的功能进行扩展，在API Server创建资源时对资源进行验证或者修改。 Istio 0.7版本就利用了Kubernets webhook实现了sidecar的自动注入。" date: 2018-05-23 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-4-25-istio-auto-injection-with-webhook/lion.jpg" +image: "/img/2018-4-25-istio-auto-injection-with-webhook/lion.jpg" published: true tags: - Kubernetes @@ -27,7 +27,7 @@ Istio 0.7版本就利用了Kubernets webhook实现了sidecar的自动注入。 ## 什么是Admission --- Admission是Kubernets中的一个术语，指的是Kubernets API Server资源请求过程中的一个阶段。如下图所示，在API Server接收到资源创建请求时，首先会对请求进行认证和鉴权，然后经过Admission处理，最后再保存到etcd。 - + 从图中看到，Admission中有两个重要的阶段，Mutation和Validation，这两个阶段中执行的逻辑如下： * Mutation diff --git a/exampleSite/content/post/2018-05-23-service_2_service_auth.md b/exampleSite/content/post/2018-05-23-service_2_service_auth.md index 3122891..d1f14da 100644 --- a/exampleSite/content/post/2018-05-23-service_2_service_auth.md +++ b/exampleSite/content/post/2018-05-23-service_2_service_auth.md @@ -8,7 +8,7 @@ showonlyimage: false excerpt: "除来自用户的访问请求以外，微服务应用中的各个微服务相互之间还有大量的访问,根据应用系统数据敏感程度不同，对于系统内微服务的访问也需要进行相应的安全控制。" author: "赵化冰" date: 2018-05-23T15:00:00 -image: "https://img.zhaohuabing.com/in-post/2018-05-23-service_2_service_auth/background.jpg" +image: "/img/2018-05-23-service_2_service_auth/background.jpg" published: true tags: - Microservice @@ -46,7 +46,7 @@ SPIFFE SVID目前支持的实现方式是X.509数字证书，在x.509 SVID中， #### Istio Auth开源实现 Istio服务网格项目的Auth组件实现了SPIFFE标准，可以为网格中服务颁发符合SPIFFE SVID标准的证书，并为服务提供身份认证，细粒度的操作鉴权以及通信加密。Istio的架构如下图所示： - + Istio Auth采用了Kubernetes的service account来作为服务标识，其SPIFFE ID的格式为spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>，其中各组成部分如下： * domain 域名 diff --git a/exampleSite/content/post/2018-05-24-set_up_my_ubuntu_desktop.md b/exampleSite/content/post/2018-05-24-set_up_my_ubuntu_desktop.md index 608ee69..78fb590 100644 --- a/exampleSite/content/post/2018-05-24-set_up_my_ubuntu_desktop.md +++ b/exampleSite/content/post/2018-05-24-set_up_my_ubuntu_desktop.md @@ -5,7 +5,7 @@ description: "Everything about setting up my own ubuntu desktop, it's just a Not excerpt: "Everything about setting up my own ubuntu desktop, it's just a Note in case I need it later" date: 2018-05-24 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-05-23-service_2_service_auth/background.jpg" +image: "/img/2018-05-23-service_2_service_auth/background.jpg" published: true tags: - ubuntu diff --git a/exampleSite/content/post/2018-06-02-istio08.md b/exampleSite/content/post/2018-06-02-istio08.md index 42b624a..178baa6 100644 --- a/exampleSite/content/post/2018-06-02-istio08.md +++ b/exampleSite/content/post/2018-06-02-istio08.md @@ -7,7 +7,7 @@ excerpt: "Istio 0.8 Release新特性" author: "赵化冰" date: 2018-06-02 description: "在6月1日这一天的早上，Istio社区宣布发布0.8 Release，除了常规的故障修复和性能改进外，这个儿童节礼物里面还有什么值得期待内容呢？让我们来看一看：" -image: "https://img.zhaohuabing.com/in-post/2018-06-02-istio08/background.jpg" +image: "/img/2018-06-02-istio08/background.jpg" published: true tags: - Istio @@ -27,7 +27,7 @@ URL: "/2018/06/02/istio08/" 新版本中不再使用K8s中的Ingress，转而采用Gateway来统一配置Service Mesh中的各个HTTP/TCP负载均衡器。Gateway可以是处理入口流量的Ingress Gateway，负责Service Mesh内部各个服务间通信的Sidecar Proxy，也可以是负责出口流量的Egress Gateway。 Mesh中涉及到的三类Gateway: - + 该变化的原因是K8s中的Ingress对象功能过于简单，不能满足Istio灵活的路由规则需求。在0.8版本中，L4-L6的配置和L7的配置被分别处理，Gateway中只配置L4-L6的功能，例如暴露的端口，TLS设置。然后用户可以采用VirtualService来配置标准的Istio规则，并和Gateway进行绑定。 diff --git a/exampleSite/content/post/2018-06-04-introducing-the-istio-v1alpha3-routing-api.md b/exampleSite/content/post/2018-06-04-introducing-the-istio-v1alpha3-routing-api.md index b4d00dc..ecf3cf1 100644 --- a/exampleSite/content/post/2018-06-04-introducing-the-istio-v1alpha3-routing-api.md +++ b/exampleSite/content/post/2018-06-04-introducing-the-istio-v1alpha3-routing-api.md @@ -6,7 +6,7 @@ excerpt: "介绍Istio v1alpha3 routing API及其设计原则" description: "介绍Istio v1alpha3 routing API及其设计原则" date: 2018-06-04 author: "赵化冰" -image: "https://img.zhaohuabing.com/in-post/2018-06-04-introducing-the-istio-v1alpha3-routing-api/background.jpg" +image: "/img/2018-06-04-introducing-the-istio-v1alpha3-routing-api/background.jpg" published: true tags: - Istio @@ -36,7 +36,7 @@ URL: "/2018/06/04/introducing-the-istio-v1alpha3-routing-api/" 在一个典型的网格中，通常有一个或多个用于终结外部TLS链接，将流量引入网格的负载均衡器（我们称之为gateway）。 然后流量通过边车网关（sidecar gateway）流经内部服务。 应用程序使用外部服务的情况也很常见（例如访问Google Maps API），一些情况下，这些外部服务可能被直接调用；但在某些部署中，网格中所有访问外部服务的流量可能被要求强制通过专用的出口网关（Egress gateway）。 下图描绘了网关在网格中的使用情况。 - + 考虑到上述因素，`v1alpha3`引入了以下这些新的配置资源来控制进入网格，网格内部和离开网格的流量路由。 @@ -48,7 +48,7 @@ URL: "/2018/06/04/introducing-the-istio-v1alpha3-routing-api/" `VirtualService`，`DestinationRule`和`ServiceEntry`分别替换了原API中的`RouteRule`，`DestinationPolicy`和`EgressRule`。 `Gateway`是一个独立于平台的抽象，用于对流入专用中间设备的流量进行建模。 下图描述了跨多个配置资源的控制流程。 - + ### Gateway [Gateway](https://istio.io/docs/reference/config/istio.networking.v1alpha3/#Gateway)用于为HTTP / TCP流量配置负载均衡器，并不管该负载均衡器将在哪里运行。 网格中可以存在任意数量的Gateway，并且多个不同的Gateway实现可以共存。 实际上，通过在配置中指定一组工作负载（Pod）标签，可以将Gateway配置绑定到特定的工作负载，从而允许用户通过编写简单的Gateway Controller来重用现成的网络设备。 |