2 lines
66 KiB
JSON
2 lines
66 KiB
JSON
|
||
[{"author":null,"categories":["tips"],"content":"Authoring mathematical and chemical equations Cleanwhite theme now has built-in KaTeX\\KaTeXKATEX support, so that you can easily include complex mathematical formulae into your web page, either inline or centred on its own line. The theme uses Hugo\u0026amp;rsquo;s embedded instance of the KaTeX display engine to render mathematical markup to HTML at build time. With this server side rendering of formulae, the same output is produced, regardless of your browser or your environment.\nLaTeX\\LaTeXLATEX is a high-quality typesetting system for the production of technical and scientific documentation. Due to its excellent math typesetting capabilities, TeX\\TeXTEX became the de facto standard for the communication and publication of scientific documents, especially if these documents contain a lot of mathematical formulae. Designed and mostly written by Donald Knuth, the initial version was released in 1978. Dating back that far, LaTeX\\LaTeXLATEX has pdf as its primary output target and is not …","date":1751760000,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":1000,"html":"Cleanwhite theme now has built-in support for authoring mathematical or chemical equations","keywords":null,"kind":"page","lang":"en","lastmod":1751760000,"objectID":"5703568c0e41811b8e59a2a26da1e726","permalink":"https://davidpaulyoung.com/2025/07/06/mathematical-formulae/","publishdate":"2025-07-06T00:00:00Z","readingtime":5,"relpermalink":"/2025/07/06/mathematical-formulae/","section":"post","tags":["Math","KaTeX"],"title":"Authoring mathematical formulae","type":"post","url":"/2025/07/06/mathematical-formulae/","weight":0,"wordcount":933},{"author":null,"categories":null,"content":"Clean White Theme for Hugo CleanWhite is a clean, elegant, but fully functional blog theme for Hugo. Here is a live demo site using this theme.\nIt is based on huxblog Jekyll Theme and Clean Blog Jekyll Theme.\nThese two upstream projects have done awesome jobs to create a blog theme, what I\u0026amp;rsquo;m doing here is porting it to Hugo, of which I like the simplicity and the much faster compiling speed. Some other features which I think could be useful, such as site search with algolia and proxy for Disqus access in China, have also been built in the CleanWhite theme. Other fancy features of upstream projects are not supported by this Hugo theme, I\u0026amp;rsquo;d like to make it as simple as possible and only focus on blog purpose, at least for now. While I created this theme, I followed the Hugo theme best practice and tried to make every part of the template as a replaceable partial html, so it could be much easier for you to make your customization based on it.\nScreenshots Home Post Search …","date":1546992000,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":1100,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":1546992000,"objectID":"2f05902e7435de187bb5303fb74f55e2","permalink":"https://davidpaulyoung.com/post/readme/","publishdate":"2019-01-09T00:00:00Z","readingtime":3,"relpermalink":"/post/readme/","section":"post","tags":null,"title":"Clean White Theme for Hugo","type":"post","url":"/post/readme/","weight":0,"wordcount":1083},{"author":null,"categories":["Tech"],"content":"到目前为止，Istio提供了一个简单的API来进行流量管理，该API包括了四种资源：RouteRule，DestinationPolicy，EgressRule和Ingress（直接使用了Kubernets的Ingress资源）。借助此API，用户可以轻松管理Istio服务网格中的流量。该API允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等等，所有这些功能都不必更改应用程序本身的代码。\n虽然目前API的功能已被证明是Istio非常引人注目的一部分，但用户的反馈也表明，这个API确实有一些缺点，尤其是在使用它来管理包含数千个服务的非常大的应用程序，以及使用HTTP以外的协议时。 此外，使用Kubernetes Ingress资源来配置外部流量的方式已被证明不能满足需求。\n为了解决上述缺陷和其他的一些问题，Istio引入了新的流量管理API v1alpha3，新版本的API将完全取代之前的API。 尽管v1alpha3和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧API的模型需要进行手动转换。 Istio接下来的几个版本中会提供一个新旧模型的转换工具。\n为了证明该非兼容升级的必要性，v1alpha3 API经历了漫长而艰苦的社区评估过程，以希望新的API能够大幅改进，并经得起时间考验。 在本文中，我们将介绍新的配置模型，并试图解释其后面的一些动机和设计原则。\n设计原则 路由模型的重构过程中遵循了一些关键的设计原则：\n除支持声明式（意图）配置外，也支持显式指定模型依赖的基础设施。例如，除了配置入口网关（的功能特性）之外，负责实现 入口网关功能的组件（Controller）也可以在模型指定。 编写模型时应该“生产者导向”和“以Host为中心”，而不是通过组合多个规则来编写模型。 例如，所有与特定Host关联的规则被配置在一起，而不是单独配置。 将路由与路由后行为清晰分开。 v1alpha3中的配置资源 在一个典型的网格中，通常有一个或多个用于终结外部TLS链接，将流量引入网格的负载均衡器（我们称之为gateway）。 然后流量通过边车网关（sidecar gateway）流经内部服务。 应用程序使用外部服务的情况也很常见（例如访问Google Maps API），一些情况下，这些外部服务可能被直接调用；但在某些部署中，网格中所 …","date":1528070400,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":5500,"html":"介绍Istio v1alpha3 routing API及其设计原则","keywords":null,"kind":"page","lang":"en","lastmod":1528070400,"objectID":"419548ad13183dac6d96760c9815824b","permalink":"https://davidpaulyoung.com/2018/06/04/introducing-the-istio-v1alpha3-routing-api/","publishdate":"2018-06-04T00:00:00Z","readingtime":11,"relpermalink":"/2018/06/04/introducing-the-istio-v1alpha3-routing-api/","section":"post","tags":["Istio"],"title":"Istio v1aplha3 routing API介绍(译文）","type":"post","url":"/2018/06/04/introducing-the-istio-v1alpha3-routing-api/","weight":0,"wordcount":5412},{"author":null,"categories":["Tech"],"content":" 在6月1日这一天的早上，Istio社区宣布发布0.8 Release，除了常规的故障修复和性能改进外，这个儿童节礼物里面还有什么值得期待内容呢？让我们来看一看：\nNetworking 改进的流量管理模型 0.8版本采用了新的流量管理配置模型v1alpha3 Route API。新版本的模型添加了一些新的特性，并改善了之前版本模型中的可用性问题。主要的改动包括：\nGateway 新版本中不再使用K8s中的Ingress，转而采用Gateway来统一配置Service Mesh中的各个HTTP/TCP负载均衡器。Gateway可以是处理入口流量的Ingress Gateway，负责Service Mesh内部各个服务间通信的Sidecar Proxy，也可以是负责出口流量的Egress Gateway。\nMesh中涉及到的三类Gateway: 该变化的原因是K8s中的Ingress对象功能过于简单，不能满足Istio灵活的路由规则需求。在0.8版本中，L4-L6的配置和L7的配置被分别处理，Gateway中只配置L4-L6的功能，例如暴露的端口，TLS设置。然后用户可以采用VirtualService来配置标准的Istio规则，并和Gateway进行绑定。\nVirtualService 采用VirtualService代替了alpha2模型中的RouteRule。采用VirtualService有两个优势：\n可以把一个服务相关的规则放在一起管理\n例如下面的路由规则，发向reviews的请求流量缺省destination为v1，如果user为jason则路由到v2。在v1模型中需要采用两条规则来实现，采用VirtualService后放到一个规则下就可以实现。\napiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: cookie: regex: \u0026amp;#34;^(.*?;)?(user=jason)(;.*)?$\u0026amp;#34; route: - destination: host: reviews subset: v2 - route: - destination: …","date":1527897600,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":1800,"html":"在6月1日这一天的早上，Istio社区宣布发布0.8 Release，除了常规的故障修复和性能改进外，这个儿童节礼物里面还有什么值得期待内容呢？让我们来看一看：","keywords":null,"kind":"page","lang":"en","lastmod":1527897600,"objectID":"5419b65011b3dcb9020c0728e6d70695","permalink":"https://davidpaulyoung.com/2018/06/02/istio08/","publishdate":"2018-06-02T00:00:00Z","readingtime":4,"relpermalink":"/2018/06/02/istio08/","section":"post","tags":["Istio"],"title":"Istio 0.8 Release发布","type":"post","url":"/2018/06/02/istio08/","weight":0,"wordcount":1796},{"author":null,"categories":["Tips"],"content":"Generate SSH Key Pair ssh-keygen -C \u0026amp;#34;zhaohuabing@gmail.com\u0026amp;#34; Shadowsocks Install shadowsokcs\nsudo apt-get install python3-pip sudo pip3 install shadowsocks Create config at config/shadowsocks.json, with the following content:\n{ \u0026amp;#34;server\u0026amp;#34;:\u0026amp;#34;remote-shadowsocks-server-ip-addr\u0026amp;#34;, \u0026amp;#34;server_port\u0026amp;#34;:443, \u0026amp;#34;local_address\u0026amp;#34;:\u0026amp;#34;127.0.0.1\u0026amp;#34;, \u0026amp;#34;local_port\u0026amp;#34;:1080, \u0026amp;#34;password\u0026amp;#34;:\u0026amp;#34;your-passwd\u0026amp;#34;, \u0026amp;#34;timeout\u0026amp;#34;:300, \u0026amp;#34;method\u0026amp;#34;:\u0026amp;#34;aes-256-cfb\u0026amp;#34;, \u0026amp;#34;fast_open\u0026amp;#34;:false, \u0026amp;#34;workers\u0026amp;#34;:1 } Start a local socks proxy\nsudo sslocal -c config/shadowsocks.json -d start In case there is an openssl error, modify shadowsocks source file.\nsudo vi /usr/local/lib/python3.6/dist-packages/shadowsocks/crypto/openssl.py :%s/cleanup/reset/gc Convert shadowsocks socks proxy to http proxy\nsudo apt-get install polipo echo \u0026amp;#34;socksParentProxy = localhost:1080\u0026amp;#34; | sudo tee -a /etc/polipo/config sudo service polipo restart Http proxy now is …","date":1527120000,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":200,"html":"Everything about setting up my own ubuntu desktop, it's just a Note in case I need it later","keywords":null,"kind":"page","lang":"en","lastmod":1527120000,"objectID":"acef740336515250f115284b46f1f096","permalink":"https://davidpaulyoung.com/2018/05/24/set_up_my_ubuntu_desktop/","publishdate":"2018-05-24T00:00:00Z","readingtime":1,"relpermalink":"/2018/05/24/set_up_my_ubuntu_desktop/","section":"post","tags":["ubuntu"],"title":"Everything about Setting Up My Ubuntu Desktop","type":"post","url":"/2018/05/24/set_up_my_ubuntu_desktop/","weight":0,"wordcount":121},{"author":null,"categories":["Tech"],"content":"外部系统访问控制 除用户访问和微服务之间的相互访问外，外部的第三方系统也可能需要访问系统内部的微服务。例如在上一篇博客的网上商店例子中，外部的推荐服务可能需要接入系统，以获取商店的商品目录信息。相对于内部服务之间的访问而言，外部系统的访问需要进行严格的安全控制。\n使用账号进行控制 可以为外部系统创建一个用户账号，类似普通用户一样对外部系统的账号进行管理，并使用该账号对外部系统进行认证和权限控制。\n采用这种方式的问题是难以处理用户相关的敏感数据。因为外部系统自身也是微服务系统中的一个用户账号，因此该外部系统只能访问该账号自身的数据和一些不敏感的公共数据，而不能访问和用户相关的数据。例如在网上商店的例子中，外部系统可以采用该方式访问商品目录信息，但不应允许访问用户历史购买记录，用户余额等信息。\nAPI Token 是一个API Token（又称API Key）可以控制对用户敏感数据的访问。微服务应用提供一个API Token的生成界面，用户登录后可以生成自己的API Token，并在第三方应用使用该API Token访问微服务的API。在这种情况下，一般只允许第三方应用访问该Token所属用户自身的数据，而不能访问其他用户的敏感私有数据。\n例如Github就提供了Personal API Token功能，用户可以在Github的开发者设置界面中创建Token，然后使用该Token来访问Github的API。在创建Token时，可以设置该Token可以访问用户的哪些数据，如查看Repo信息，删除Repo，查看用户信息，更新用户信息等。\n使用API Token来访问Github API\ncurl -u zhaohuabing:fbdf8e8862252ed0f3ba9dba4e328c01ac93aeec https://api.github.com/user 不用试了,这不是我的真实API Token, just for demonstration :-)\n使用API Token而不是直接使用用户名/密码来访问API的好处是降低了用户密码暴露的风险，并且可以随时收回Token的权限而不用修改密码。\n由于API Token只能访问指定用户的数据，因此适合于用户自己开发一些脚本或小程序对应用中自己的数据进行操作。\nOAuth 某些第三方应用需要访问不同用户的数据，或者对多个用 …","date":1527098400,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":2400,"html":"一些外部的第三方系统可能需要访问系统内部的微服务。例如在网上商店的例子中，外部的推荐服务可能需要接入系统，以获取商店的商品目录信息。相对于内部服务之间的访问而言，外部系统的访问需要进行严格的安全控制。","keywords":null,"kind":"page","lang":"en","lastmod":1527098400,"objectID":"bcf92db93ffdd43ba91e4322cf6c6ece","permalink":"https://davidpaulyoung.com/2018/05/23/external_system_auth/","publishdate":"2018-05-23T18:00:00Z","readingtime":5,"relpermalink":"/2018/05/23/external_system_auth/","section":"post","tags":["Microservice","Security"],"title":"微服务安全沉思录之三","type":"post","url":"/2018/05/23/external_system_auth/","weight":0,"wordcount":2349},{"author":null,"categories":["Tech"],"content":"服务间认证与鉴权 除来自用户的访问请求以外，微服务应用中的各个微服务相互之间还有大量的访问，包括下述场景：\n用户间接触发的微服务之间的相互访问 例如在一个网上商店应用中，用户访问购物车微服务进行结算时，购物车微服务可能需要访问用户评级微服务获取用户的会员级别，以得到用户可以享受购物折扣。 非用户触发的微服务之间的相互访问 例如数据同步或者后台定时任务导致的微服务之间的相互访问。 根据应用系统的数据敏感程度的不同，对于系统内微服务的相互访问可能有不同的安全要求。\n对微服务之间的相互访问不进行安全控制 在某些场景下，可以假设同一应用中微服务之间的相互访问都是可信的。在这种情况下，应用依赖于内部网络的防火墙及其他网络安全措施来保证安全性。在这种情况对入侵者攻击进入内部网络后没有保护措施。入侵者可以对微服务间的通信进行典型的中间人攻击，例如窃听通信内容，伪造和修改通信数据，甚至假装为一个合法的微服务进行通信。\n采用Service Account(服务账号)进行安全控制 “内部网络中微服务之间的所有通信都是可信的”这个假设在某些场景下是不成立的，特别是在微服务中保存有用户信息这种非常重要的数据的情况下。将敏感信息直接暴露在内部攻击下的做法是非常危险的。 解决该问题的一种方案是使用服务账号来对微服务之间的相互访问进行控制。\n用户权限控制的一个普遍方法是使用”用户账号（User Account）”来标识一个系统用户，并对其进行身份认证和操作鉴权。类似地，可以为系统中每一个服务也创建一个账号，称为”服务账号(Service Accout)“。 该服务账号表示了微服务的身份，以用于控制该微服务对系统中其它微服务的访问权限，如可以对哪些微服务的哪些资源进行何种操作。当一个微服务访问另一个微服务时，被访问的微服务需要验证访问者的服务账号，以确定其身份和资源操作权限。\nSPIFEE标准 Secure Production Identity Framework For Everyone (SPIFFE)是一套服务之间相互进行身份识别的标准，主要包含以下内容：\nSPIFFE ID标准，SPIFFE ID是服务的唯一标识，实现为统一资源标识\u0026amp;quot;Uniform Resource Identifier (URI)”符。 SVID(SPIFFE Verifiable Identity …","date":1527087600,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":2000,"html":"除来自用户的访问请求以外，微服务应用中的各个微服务相互之间还有大量的访问,根据应用系统数据敏感程度不同，对于系统内微服务的访问也需要进行相应的安全控制。","keywords":null,"kind":"page","lang":"en","lastmod":1527087600,"objectID":"d7d93ee7d2a2b13ec20c157389fd7a3a","permalink":"https://davidpaulyoung.com/2018/05/23/service_2_service_auth/","publishdate":"2018-05-23T15:00:00Z","readingtime":4,"relpermalink":"/2018/05/23/service_2_service_auth/","section":"post","tags":["Microservice","Security"],"title":"微服务安全沉思录之二","type":"post","url":"/2018/05/23/service_2_service_auth/","weight":0,"wordcount":1935},{"author":null,"categories":["Tech"],"content":" 这段时间对之前微服务安全相关的一些想法进行了进一步总结和归纳，理清了在之前文章里面没有想得太清楚的地方，例如服务间的认证与鉴权以及用户身份在服务调用链中的传递。\n在这一系列文章里，我将尝试分为三个部分对微服务安全进行系统阐述：用户访问认证与鉴权，服务间认证与鉴权，外部系统访问控制。\n目录 {:.no_toc}\n目录 {:toc} 前言 微服务架构的引入为软件应用带来了诸多好处：包括小开发团队，缩短开发周期，语言选择灵活性，增强服务伸缩能力等。与此同时，也引入了分布式系统的诸多复杂问题。其中一个挑战就是如何在微服务架构中实现一个灵活，安全，高效的认证和鉴权方案。\n相对于传统单体应用，微服务架构下的认证和鉴权涉及到场景更为复杂，涉及到用户访问微服务应用，第三方应用访问微服务应用，应用内多个微服务之间相互访问等多种场景，每种场景下的认证和鉴权方案都需要考虑到，以保证应用程序的安全性。本系列博文将就此问题进行一次比较完整的探讨。 微服务认证和鉴权涉及到的三种场景 用户认证和鉴权 用户身份认证 一个完整的微服务应用是由多个相互独立的微服务进程组成的，对每个微服务的访问都需要进行用户认证。如果将用户认证的工作放到每个微服务中，存在下面一些问题：\n需要在各个微服务中重复实现这部分公共逻辑。虽然我们可以使用代码库复用部分代码，但这又会导致所有微服务对特定代码库及其版本存在依赖，影响微服务语言/框架选择的灵活性。 将认证和鉴权的公共逻辑放到微服务实现中违背了单一职责原理，开发人员应重点关注微服务自身的业务逻辑。 用户需要分别登录以访问系统中不同的服务。 由于在微服务架构中以API Gateway作为对外提供服务的入口，因此可以在API Gateway处提供统一的用户认证，用户只需要登录一次，就可以访问系统中所有微服务提供的服务。\n用户状态保持 HTTP是一个无状态的协议，对服务器来说，用户的每次HTTP请求是相互独立的。互联网是一个巨大的分布式系统，HTTP协议作为互联网上的一个重要协议，在设计之初要考虑到大量应用访问的效率问题。无状态意味着服务端可以把客户端的请求根据需要发送到集群中的任何一个节点，HTTP的无状态设计对负载均衡有明显的好处，由于没有状态，用户请求可以被分发到任意一个服务器，应用也可以在靠近用户的网络边缘部署缓存服务器。对于不需要身份认证的服务，例如浏览新闻网页等 …","date":1527069600,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":3100,"html":"这段时间对之前微服务安全相关的一些想法进行了进一步总结和归纳，理清在之前文章里面没有想得太清楚的地方，例如服务间的认证与鉴权以及用户身份在服务调用链中的传递。在这一系列博客里面将分为三个部分对微服务安全进行系统阐述：用户访问认证与鉴权，服务间认证与鉴权，外部系统访问控制。","keywords":null,"kind":"page","lang":"en","lastmod":1527069600,"objectID":"3fc17cbcf909103e423326182d72a807","permalink":"https://davidpaulyoung.com/2018/05/22/user_authentication_authorization/","publishdate":"2018-05-23T10:00:00Z","readingtime":7,"relpermalink":"/2018/05/22/user_authentication_authorization/","section":"post","tags":["Microservice","Security"],"title":"微服务安全沉思录之一","type":"post","url":"/2018/05/22/user_authentication_authorization/","weight":0,"wordcount":3093},{"author":null,"categories":["Tech"],"content":"前言 Kubernets 1.9版本引入了Admission Webhook(web 回调)扩展机制，通过Webhook,开发者可以非常灵活地对Kubernets API Server的功能进行扩展，在API Server创建资源时对资源进行验证或者修改。\n使用webhook的优势是不需要对API Server的源码进行修改和重新编译就可以扩展其功能。插入的逻辑实现为一个独立的web进程，通过参数方式传入到kubernets中，由kubernets在进行自身逻辑处理时对扩展逻辑进行回调。\nIstio 0.7版本就利用了Kubernets webhook实现了sidecar的自动注入。\n什么是Admission Admission是Kubernets中的一个术语，指的是Kubernets API Server资源请求过程中的一个阶段。如下图所示，在API Server接收到资源创建请求时，首先会对请求进行认证和鉴权，然后经过Admission处理，最后再保存到etcd。 从图中看到，Admission中有两个重要的阶段，Mutation和Validation，这两个阶段中执行的逻辑如下：\nMutation\nMutation是英文“突变”的意思,从字面上可以知道在Mutation阶段可以对请求内容进行修改。\nValidation\n在Validation阶段不允许修改请求内容，但可以根据请求的内容判断是继续执行该请求还是拒绝该请求。\nAdmission webhook 通过Admission webhook,可以加入Mutation和Validation两种类型的webhook插件，这些插件和Kubernets提供的预编译的Admission插件具有相同的能力。可以想到的用途包括：\n修改资源。例如Istio就通过Admin Webhook在Pod资源中增加了Envoy sidecar容器。 自定义校验逻辑，例如对资源名称有一些特殊要求。或者对自定义资源的合法性进行校验。 采用Webhook自动注入Istio Sidecar Kubernets版本要求 webhook支持需要Kubernets1.9或者更高的版本,使用下面的命令确认kube-apiserver的Admin webhook功能已启用。\nkubectl api-versions | grep …","date":1527033600,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":1200,"html":"Kubernets 1.9版本引入了Admission Webhook(web 回调)扩展机制，通过Webhook,开发者可以非常灵活地对Kubernets API Server的功能进行扩展，在API Server创建资源时对资源进行验证或者修改。 Istio 0.7版本就利用了Kubernets webhook实现了sidecar的自动注入。","keywords":null,"kind":"page","lang":"en","lastmod":1527033600,"objectID":"61cbee2b7380aaa6e9b9f882840da6a0","permalink":"https://davidpaulyoung.com/2018/05/23/istio-auto-injection-with-webhook/","publishdate":"2018-05-23T00:00:00Z","readingtime":3,"relpermalink":"/2018/05/23/istio-auto-injection-with-webhook/","section":"post","tags":["Kubernetes","Istio"],"title":"Istio Sidecar自动注入原理","type":"post","url":"/2018/05/23/istio-auto-injection-with-webhook/","weight":0,"wordcount":1133},{"author":null,"categories":["Tech"],"content":" This series of articles are my notes of \u0026amp;ldquo;Bitcoin and Cryptocurrency Technologies\u0026amp;rdquo; online course.\nTable of Content {:.no_toc}\nTable of Content {:toc} Scrooge Coin Transaction Scrooge Coin programming assignment is a little bit tricky, the video of this lesson hasn\u0026amp;rsquo;t explained some implementation details. To help you understand the transaction data structure used in Scrooge Coin, I draw this diagram: 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.\nEvery output is correlated to the public key of the receiver, which is his/her ScroogeCoin address.\nIn the first transaction, we assume that Scrooge has created 10 coins and assigned them to himself, we don\u0026amp;rsquo;t doubt that because the system-Scroogecoin has a building rule …","date":1526900400,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":800,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":1526900400,"objectID":"bf66956078def1376b24541987e8dd17","permalink":"https://davidpaulyoung.com/2018/05/21/algolia-integration-with-jekyll/","publishdate":"2018-05-21T11:00:00Z","readingtime":2,"relpermalink":"/2018/05/21/algolia-integration-with-jekyll/","section":"post","tags":["Jekyll:q","Bitcoin"],"title":"使用Algolia为Gitpage博客提供站内搜索","type":"post","url":"/2018/05/21/algolia-integration-with-jekyll/","weight":0,"wordcount":792},{"author":null,"categories":["Life"],"content":"寻浮云牧场不遇 五一节前的一周内，几个朋友就纷纷坐不住了，一个二个不再安心上班，开始在微信群里讨论过节要到哪里耍。 大家思来想去，最后决定还是去理县方向。因为根据多年自驾的经验，只要出了汶川，沿途都是风景。\n放假第一天和第二天上午老婆加班，我在家里陪女儿做作业，提前把车油加好，准备路上的衣物。第二天中午老婆上完班，我迫不及待开着小狮子就向都汶高速出发了。虽然加班耽误了一天半，但我们这次也算错峰出行了，一路上畅通无阻，心情自然也比较愉快。 开车1个多点小时就赶到了汶川，这时朋友一家刚在汶川县城吃完午饭，我们在出汶川不远，桃坪羌寨附近胜利会师了。\n两位领导一起协商了一下，决定先开车去通化乡的“浮云牧场”看看。“浮云牧场”是最近的一个网红酒店，在通化乡山上的一个藏寨旁边。有道是：“浮云牧场”，不放牛羊，只牧浮云和姑娘。\n“浮云牧场”走的是网红路线，马蜂窝，微信公众号的宣传做得好，知名度较高，房间比较紧俏，在五一期间更是一房难求，而且价格也比较感人。两位领导都持家有方，指示我们上去看看风景，然后下山再找住宿。\n过了桃坪羌寨大概几公里，317国道右边有一个比较明显的指路牌，往右上山，就是到浮云牧场的路。我们兴冲冲地开车上了山，此时，我们心中向往的浮云牧场是这样子的（取图自网络）： 上山的路况还可以，但比较窄，回头弯较多，需要注意对方来车。开了将近1小时后，来到了半山腰，对面来了好几辆下山的车。由于两方相遇的路面较窄，开始堵车了。这时乘机向对方打听了山上的情况，得知酒店封路了，只有预定了房间的人才能进入浮云牧场。\n得知这个消息，此时我们的内心是崩溃的，已经开了一大半的山路，现在却得知不能进去。没有办法，大家商量后还是决定下山。不过“塞翁失马，焉知非福”，这次没进入浮云牧场，为第二天探秘一个新景点埋下伏笔，现在暂时不表。于是我和朋友调转车头，悻悻下山，败意而回。\n夜宿甘堡藏寨 下山后，大家商量晚上的住宿。我觉得桃坪羌寨靠路边，环境也一般，提议去靠近理县的甘堡藏寨。朋友因为在桃坪羌寨住过了，因此也想去另外的地方试试。于是一路向理县方向进发，由于限速较低，车辆也开始多了起来，感觉没多远的距离，开了接近1小时，6点左右来到了甘堡藏寨。\n最后一个靠小河边的藏家乐入住，一个标间240元，包3个人一顿晚饭，一顿早饭。我和朋友两家分别在二楼和三楼的两间房间住下。这里得表扬一下领导，每次出来耍选 …","date":1525132800,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":3600,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":1525132800,"objectID":"14429f8bcce027e828700689f3857119","permalink":"https://davidpaulyoung.com/2018/05/01/may-day-jiulonghu/","publishdate":"2018-05-01T00:00:00Z","readingtime":8,"relpermalink":"/2018/05/01/may-day-jiulonghu/","section":"post","tags":["Travel"],"title":"川西秘境探险","type":"post","url":"/2018/05/01/may-day-jiulonghu/","weight":0,"wordcount":3568},{"author":null,"categories":["Tech"],"content":"前言 Helm是Kubernetes生态系统中的一个软件包管理工具。本文将介绍为何要使用Helm进行Kubernetes软件包管理，澄清Helm中使用到的相关概念，并通过一个具体的示例学习如何使用Helm打包，分发，安装，升级及回退Kubernetes应用。\nKubernetes应用部署的挑战 让我们首先来看看Kubernetes，kubernetes提供了基于容器的应用集群管理，为容器化应用提供了部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。\nkubernetes的核心设计理念是: 用户定义应用程序的规格，而kubernetes则负责按照定义的规则部署并运行应用程序，如果应用系统出现问题导致偏离了定义的规格，kubernetes负责对其进行自动修正。例如应用规格要求部署两个实例，其中一个实例异常终止了，kubernetes会检查到并重新启动一个新的实例。\n用户通过使用kubernetes API对象来描述应用程序规格，包括Pod，Service，Volume，Namespace，ReplicaSet，Deployment，Job等等。一般这些对象需要写入一系列的yaml文件中，然后通过kubernetes命令行工具kubectl进行部署。\n以下面的wordpress应用程序为例，涉及到多个kubernetes API对象，这些kubernetes API对象分散在多个yaml文件中。\n图1： Wordpress应用程序中涉及到的kubernetes API对象 可以看到，在进行kubernetes软件部署时，我们面临下述问题：\n如何管理，编辑和更新这些这些分散的kubernetes应用配置文件？ 如何把一套的相关配置文件作为一个应用进行管理？ 如何分发和重用kubernetes的应用配置？ Helm的引入很好地解决上面这些问题。\nHelm是什么？ 很多人都使用过Ubuntu下的ap-get或者CentOS下的yum, 这两者都是Linux系统下的包管理工具。采用apt-get/yum,应用开发者可以管理应用包之间的依赖关系，发布应用；用户则可以以简单的方式查找、安装、升级、卸载应用程序。\n我们可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis (https://deis.com/) 开发的一个用于kubernetes的包 …","date":1523890800,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":5000,"html":"Helm是Kubernetes生态系统中的一个软件包管理工具。本文将介绍为何要使用Helm进行Kubernetes软件包管理，澄清Helm中使用到的相关概念，并通过一个具体的示例学习如何使用Helm打包，分发，安装，升级及回退Kubernetes应用。","keywords":null,"kind":"page","lang":"en","lastmod":1523890800,"objectID":"8160a1bd8df0fbf81c4f36a3c6e7d3af","permalink":"https://davidpaulyoung.com/2018/04/16/using-helm-to-deploy-to-kubernetes/","publishdate":"2018-04-16T15:00:00Z","readingtime":10,"relpermalink":"/2018/04/16/using-helm-to-deploy-to-kubernetes/","section":"post","tags":["Kubernetes","Helm"],"title":"Helm介绍","type":"post","url":"/2018/04/16/using-helm-to-deploy-to-kubernetes/","weight":0,"wordcount":4996},{"author":null,"categories":["Tech"],"content":"Service Mesh vs API Gateway 在前一篇关于Service Mesh的文章中,我提到了几个关于Service Mesh和API Gateway之间关系的问题，在本篇文章中，我打算就Service Mesh和API Gateway的用途进行进一步讨论。\n为了区分API Gateway和Service Mesh，让我们先分别看看两者各自的关键特征。\nAPI Gateway: 将服务作为被管理的API向外部暴露 使用API Gateway的主要目的是将微服务作为被管理的API暴露（给外部系统）。因此，我们在API Gateway层开发的API或者边界服务对外提供了业务功能。\nAPI/边界服务调用下游的组合或者原子微服务，通过组合/混装多个下游微服务的方式来提供业务逻辑。\n在API/Edge服务调用下游服务时，需要采用一种可靠的通信方式，应用了断路器，超时，负载均衡/故障转移等可靠性模式。因此大部分的API Gateway解决方案都内置了这些特性。\nAPI Gateway也内置了以下特性的支持，包括：服务发现，分析（可见性：性能指标，监控，分布式日志，分布式调用追踪）和安全。\nAPI Gateway和API管理生态系统的其他组件的关系紧密，比如： API 市场/商店， API 发布门户。\nService Mesh：微服务的网络通信基础设施 现在我们来看看Service Mesh有哪些不同。\nService Mesh是一个网络通信基础设施， 可以用于将应用层的网络通信功能从你的服务代码中剥离出来。\n采用Service Mesh， 你不用在服务代码中实现用于可靠通信的模式如断路，超时等，类似地，Service Mesh也提供了服务发现，服务可见性等其他功能。\nAPI Gateway和Service Mesh实践 API Gateway和Service Mesh之间的主要不同点：API Gateway是暴露API/边界服务的关键组件，而Service Mesh则仅仅是一个服务间通信的基础设施，并不了解应用中的业务逻辑。\n下图说明了API Gateway和Service Mesh的关系。如同前面所说，这两者之间也有一些重叠的部分（例如断路器等），但重要的是需要理解这两者是用于完全不同的用途。\n图1： API Gateway和Service Mesh实践\n如上 …","date":1523439120,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":1700,"html":"API Gateway和Service Mesh的关系是我最近一直在思考的问题，也和同事及社区的朋友之间进行了一些讨论。这篇短文很清晰地总结了两者之间的相似之处以及这两者在微服务架构中的不同用途。","keywords":null,"kind":"page","lang":"en","lastmod":1523439120,"objectID":"10512631762a4eb4fe14a47b7cb61d54","permalink":"https://davidpaulyoung.com/2018/04/11/service-mesh-vs-api-gateway/","publishdate":"2018-04-11T09:32:00Z","readingtime":4,"relpermalink":"/2018/04/11/service-mesh-vs-api-gateway/","section":"post","tags":["Microservice","Service Mesh","API Gateway"],"title":"Service Mesh 和 API Gateway的关系探讨（译文）","type":"post","url":"/2018/04/11/service-mesh-vs-api-gateway/","weight":0,"wordcount":1697},{"author":null,"categories":["Tech"],"content":"微服务架构的演进 作为一种架构模式，微服务将复杂系统切分为数十乃至上百个小服务，每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改，并带来了语言和框架选择灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。\n另一方面，当应用被拆分为多个微服务进程后，进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性。\n该变化带来了分布式系统的一系列问题，例如：\n如何找到服务的提供方？ 如何保证远程方法调用的可靠性？ 如何保证服务调用的安全性？ 如何降低服务调用的延迟？ 如何进行端到端的调试？ 另外生产部署中的微服务实例也增加了运维的难度,例如：\n如何收集大量微服务的性能指标已进行分析？ 如何在不影响上线业务的情况下对微服务进行升级？ 如何测试一个微服务集群部署的容错和稳定性？ 这些问题涉及到成百上千个服务的通信、管理、部署、版本、安全、故障转移、策略执行、遥测和监控等，要解决这些微服务架构引入的问题并非易事。\n让我们来回顾一下微服务架构的发展过程。在出现服务网格之前，我们最开始在微服务应用程序内理服务之间的通讯逻辑，包括服务发现，熔断，重试，超时，加密，限流等逻辑。 在一个分布式系统中，这部分逻辑比较复杂，为了为微服务应用提供一个稳定、可靠的基础设施层，避免大家重复造轮子，并减少犯错的可能，一般会通过对这部分负责服务通讯的逻辑进行抽象和归纳，形成一个代码库供各个微服务应用程序使用，如下图所示： 公共的代码库减少了应用程序的开发和维护工作量，降低了由应用开发人员单独实现微服务通讯逻辑出现错误的机率，但还是存在下述问题：\n微服务通讯逻辑对应用开发人员并不透明，应用开发人员需要理解并正确使用代码\t库，不能将其全部精力聚焦于业务逻辑。 需要针对不同的语言/框架开发不同的代码库，反过来会影响微服务应用开发语言\t和框架的选择，影响技术选择的灵活性。 随着时间的变化，代码库会存在不同的版本，不同版本代码库的兼容性和大量运行\t环境中微服务的升级将成为一个难题。 可以将微服务之间的通讯基础设施层和TCP/IP协议栈进行类比。TCP/IP协议栈为操作系统中的所有应用提供基础通信服务，但TCP/IP协议栈和应用程序之间并没有紧密的耦合关系，应用只需要使用TCP/IP协议提供的底层通讯功能,并不关心 …","date":1522324800,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":8500,"html":"作为一种架构模式，微服务将复杂系统切分为数十乃至上百个小服务，每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改，并带来了语言和框架选择灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。另一方面，当应用被拆分为多个微服务进程后，进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性,本文介绍了Service Mesh模式如何应对微服务架构的这些挑战，以及Service Mesh的明星开源项目Istio。","keywords":null,"kind":"page","lang":"en","lastmod":1522324800,"objectID":"58e1fcbb286268d60015d8695e72e3b4","permalink":"https://davidpaulyoung.com/2018/03/29/what-is-service-mesh-and-istio/","publishdate":"2018-03-29T12:00:00Z","readingtime":17,"relpermalink":"/2018/03/29/what-is-service-mesh-and-istio/","section":"post","tags":["Microservice","Service Mesh","Istio"],"title":"谈谈微服务架构中的基础设施：Service Mesh与Istio","type":"post","url":"/2018/03/29/what-is-service-mesh-and-istio/","weight":0,"wordcount":8405},{"author":null,"categories":["Tips"],"content":"Ubuntu 设置docker使用http proxy sudo /etc/default/docker export http_proxy=\u0026amp;#34;http://127.0.0.1:3128/\u0026amp;#34; export https_proxy=\u0026amp;#34;http://127.0.0.1:3128/\u0026amp;#34; export HTTP_PROXY=\u0026amp;#34;http://127.0.0.1:3128/\u0026amp;#34; export HTTPS_PROXY=\u0026amp;#34;http://127.0.0.1:3128/\u0026amp;#34; 加载配置并重启docker sudo service docker restart CentOS 设置docker使用http proxy sudo mkdir -p /etc/systemd/system/docker.service.d echo \u0026amp;#39; [Service] Environment=\u0026amp;#34;HTTP_PROXY=http://proxy.foo.bar.com:80/\u0026amp;#34; \u0026amp;#39; | sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf 加载配置并重启docker sudo systemctl daemon-reload sudo systemctl restart docker ","date":1520964000,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":100,"html":"如何配置docker使用HTTP代理","keywords":null,"kind":"page","lang":"en","lastmod":1520964000,"objectID":"98b8057999561a04d562f017fde4df05","permalink":"https://davidpaulyoung.com/2018/03/13/use-docker-behind-http-proxy/","publishdate":"2018-03-13T18:00:00Z","readingtime":1,"relpermalink":"/2018/03/13/use-docker-behind-http-proxy/","section":"post","tags":["Tips","Docker"],"title":"如何配置docker使用HTTP代理","type":"post","url":"/2018/03/13/use-docker-behind-http-proxy/","weight":0,"wordcount":92},{"author":null,"categories":["Tips"],"content":"vim graphical cheat sheet Vim Jumps ^ — Move to start of line $ — Move to end of line b — Move back a word w — Move forward a word e — Move to the end of the next word Ctrl-o and Ctrl-i to go to the previous/next location you jumped to ``(two backticks) jump back to where you were gi go back to the last place you inserted a text and enter insert mode Vim Navigations { and } jump paragraph back and forth Ctrl-F/B move one screen back and forth Search the word under cursor, then n/p to jump to next/previous Enable Vim mode in bash vi ~/.inputrc set editing-mode vi\nEnable system clipboard support See if system clipboard is supported:\n$ vim --version | grep clipboard -clipboard +iconv +path_extra -toolbar +eval +mouse_dec +startuptime -xterm_clipboard Rinstall vim as vim-gnome:\nsudo apt-get install vim-gnome Select what you want using the mouse - then type to copy to clipboard:\n\u0026amp;#34;+y To paste to vim from clipboard type:\n\u0026amp;#34;+p Others Ex: open the current directory set number: show line …","date":1518174000,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":200,"html":"Vim Tips and tricks","keywords":null,"kind":"page","lang":"en","lastmod":1518174000,"objectID":"2d0e4272390337188b486ff2335caebb","permalink":"https://davidpaulyoung.com/2018/02/09/vim-tips/","publishdate":"2018-02-09T11:00:00Z","readingtime":1,"relpermalink":"/2018/02/09/vim-tips/","section":"post","tags":["Tips","Vim"],"title":"Vim Tips","type":"post","url":"/2018/02/09/vim-tips/","weight":0,"wordcount":181},{"author":null,"categories":["Tips"],"content":"Add the docker group if it doesn\u0026amp;rsquo;t already exist: sudo groupadd docker\nAdd the connected user \u0026amp;ldquo;$USER\u0026amp;rdquo; to the docker group. Change the user name to match your preferred user if you do not want to use your current user: sudo gpasswd -a $USER docker\nEither do a newgrp docker or log out/in to activate the changes to groups. ","date":1518170400,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":100,"html":"如何使用非root用户执行docker命令","keywords":null,"kind":"page","lang":"en","lastmod":1518170400,"objectID":"92d7e3e34329f74a5a955e31f5743bae","permalink":"https://davidpaulyoung.com/2018/02/09/docker-without-sudo/","publishdate":"2018-02-09T10:00:00Z","readingtime":1,"relpermalink":"/2018/02/09/docker-without-sudo/","section":"post","tags":["Tips","Docker"],"title":"如何使用非root用户执行docker命令","type":"post","url":"/2018/02/09/docker-without-sudo/","weight":0,"wordcount":59},{"author":null,"categories":["Tech"],"content":"前言 微服务架构的引入为软件应用带来了诸多好处：包括小开发团队，缩短开发周期，语言选择灵活性，增强服务伸缩能力等。与此同时，也引入了分布式系统的诸多复杂问题。其中一个挑战就是如何在微服务架构中实现一个灵活，安全，高效的认证和鉴权方案。本文将尝试就此问题进行一次比较完整的探讨。\n单体应用的实现方式 在单体架构下，整个应用是一个进程，在应用中，一般会用一个安全模块来实现用户认证和鉴权。\n用户登录时，应用的安全模块对用户身份进行验证，验证用户身份合法后，为该用户生成一个会话(Session)，并为该Session关联一个唯一的编号(Session Id)。Session是应用中的一小块内存结构，其中保存了登录用户的信息，如User name, Role, Permission等。服务器把该Session的Session Id返回给客户端，客户端将Session Id以cookie或者URL重写的方式记录下来，并在后续请求中发送给应用，这样应用在接收到客户端访问请求时可以使用Session Id验证用户身份，不用每次请求时都输入用户名和密码进行身份验证。\n备注：为了避免Session Id被第三者截取和盗用，客户端和应用之前应使用TLS加密通信，session也会设置有过期时间。\n单体应用用户登录认证序列图 客户端访问应用时，Session Id随着HTTP请求发送到应用，客户端请求一般会通过一个拦截器处理所有收到的客户端请求。拦截器首先判断Session Id是否存在，如果该Session Id存在，就知道该用户已经登录。然后再通过查询用户权限判断用户能否执行该此请求，以实现操作鉴权。 单体应用用户操作鉴权序列图 微服务认证和鉴权面临的问题 在微服务架构下，一个应用被拆分为多个微服务进程，每个微服务实现原来单体应用中一个模块的业务功能。应用拆分后，对每个微服务的访问请求都需要进行认证和鉴权。如果参考单体应用的实现方式会遇到下述问题：\n认证和鉴权逻辑需要在每个微服务中进行处理，需要在各个微服务中重复实现这部分公共逻辑。虽然我们可以使用代码库复用部分代码，但这又会导致所有微服务对特定代码库及其版本存在依赖，影响微服务语言/框架选择的灵活性。 微服务应遵循单一职责原理，一个微服务只处理单一的业务逻辑。认证和鉴权的公共逻辑不应该放到微服务实现中。 为了充分利用微服务架构的好处，实 …","date":1517659200,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":5600,"html":"微服务架构的引入为软件应用带来了诸多好处：包括小开发团队，缩短开发周期，语言选择灵活性，增强服务伸缩能力等。与此同时，也引入了分布式系统的诸多复杂问题。其中一个挑战就是如何在微服务架构中实现一个灵活，安全，高效的认证和鉴权方案。本文将尝试就此问题进行一次比较完整的探讨。","keywords":null,"kind":"page","lang":"en","lastmod":1517659200,"objectID":"c1d32da205ea082b3dd7061c39ea7e8b","permalink":"https://davidpaulyoung.com/2018/05/22/user_authentication_authorization/","publishdate":"2018-02-03T12:00:00Z","readingtime":12,"relpermalink":"/2018/05/22/user_authentication_authorization/","section":"post","tags":["Microservice","Security"],"title":"如何构建安全的微服务应用？","type":"post","url":"/2018/05/22/user_authentication_authorization/","weight":0,"wordcount":5532},{"author":null,"categories":["Tech"],"content":"前言 Nginmesh是NGINX的Service Mesh开源项目，用于Istio服务网格平台中的数据面代理。它旨在提供七层负载均衡和服务路由功能，与Istio集成作为sidecar部署，并将以“标准，可靠和安全的方式”使得服务间通信更容易。Nginmesh在今年底已经连续发布了0.2和0.3版本，提供了服务发现，请求转发，路由规则，性能指标收集等功能。\n备注：本文安装指南基于Ubuntu 16.04，在Centos上某些安装步骤的命令可能需要稍作改动。\n安装Kubernetes Cluster Kubernetes Cluster包含etcd, api server, scheduler，controller manager等多个组件，组件之间的配置较为复杂，如果要手动去逐个安装及配置各个组件，需要了解kubernetes，操作系统及网络等多方面的知识，对安装人员的能力要求较高。kubeadm提供了一个简便，快速安装Kubernetes Cluster的方式，并且可以通过安装配置文件提供较高的灵活性，因此我们采用kubeadm安装kubernetes cluster。\n首先参照kubeadm的说明文档在计划部署kubernetes cluster的每个节点上安装docker，kubeadm, kubelet 和 kubectl。\n安装docker\napt-get update apt-get install -y docker.io 使用google的源安装kubelet kubeadm和kubectl\napt-get update \u0026amp;amp;\u0026amp;amp; apt-get install -y apt-transport-https curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat \u0026amp;lt;\u0026amp;lt;EOF \u0026amp;gt;/etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl 使用kubeadmin安装 …","date":1514894400,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":2700,"html":"Nginmesh是NGINX的Service Mesh开源项目，用于Istio服务网格平台中的数据面代理。它旨在提供七层负载均衡和服务路由功能，与Istio集成作为sidecar部署，并将以“标准，可靠和安全的方式”使得服务间通信更容易。Nginmesh在今年底已经连续发布了0.2和0.3版本，提供了服务发现，请求转发，路由规则，性能指标收集等功能。本文介绍如何采用kubeadmin安装kubernetes集群并部署Nginmesh sidecar。","keywords":null,"kind":"page","lang":"en","lastmod":1514894400,"objectID":"f12f8e4e5417662ca5f2745b62aadb1e","permalink":"https://davidpaulyoung.com/2018/01/02/nginmesh-install/","publishdate":"2018-01-02T12:00:00Z","readingtime":6,"relpermalink":"/2018/01/02/nginmesh-install/","section":"post","tags":["Istio","service Mesh","nginmesh"],"title":"Nginx开源Service Mesh组件Nginmesh安装指南","type":"post","url":"/2018/01/02/nginmesh-install/","weight":0,"wordcount":2677},{"author":null,"categories":["Tech"],"content":"前言 我们知道，kubernetes的Cluster Network属于私有网络，只能在cluster Network内部才能访问部署的应用，那如何才能将Kubernetes集群中的应用暴露到外部网络，为外部用户提供服务呢？本文探讨了从外部网络访问kubernetes cluster中应用的几种实现方式。\n本文尽量试着写得比较容易理解，但要做到“深入浅出”，把复杂的事情用通俗易懂的语言描述出来是非常需要功力的，个人自认尚未达到此境界，唯有不断努力。此外，kubernetes本身是一个比较复杂的系统，无法在本文中详细解释涉及的所有相关概念，否则就可能脱离了文章的主题，因此假设阅读此文之前读者对kubernetes的基本概念如docker，container，pod已有所了解。\n另外此文中的一些内容是自己的理解，由于个人的知识范围有限，可能有误，如果读者对文章中的内容有疑问或者勘误，欢迎大家指证。\nPod和Service 我们首先来了解一下Kubernetes中的Pod和Service的概念。\nPod(容器组),英文中Pod是豆荚的意思，从名字的含义可以看出，Pod是一组有依赖关系的容器，Pod包含的容器都会运行在同一个host节点上，共享相同的volumes和network namespace空间。Kubernetes以Pod为基本操作单元，可以同时启动多个相同的pod用于failover或者load balance。\nPod的生命周期是短暂的，Kubernetes根据应用的配置，会对Pod进行创建，销毁，根据监控指标进行缩扩容。kubernetes在创建Pod时可以选择集群中的任何一台空闲的Host，因此其网络地址是不固定的。由于Pod的这一特点，一般不建议直接通过Pod的地址去访问应用。\n为了解决访问Pod不方便直接访问的问题，Kubernetes采用了Service的概念，Service是对后端提供服务的一组Pod的抽象，Service会绑定到一个固定的虚拟IP上，该虚拟IP只在Kubernetes Cluster中可见，但其实该IP并不对应一个虚拟或者物理设备，而只是IPtable中的规则，然后再通过IPtable将服务请求路由到后端的Pod中。通过这种方式，可以确保服务消费者可以稳定地访问Pod提供的服务，而不用关心Pod的创建、删除、迁移等变化以及如何用一 …","date":1511870400,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":5600,"html":"我们知道，kubernetes的Cluster Network属于私有网络，只能在cluster Network内部才能访问部署的应用，那如何才能将Kubernetes集群中的应用暴露到外部网络，为外部用户提供服务呢？本文探讨了从外部网络访问kubernetes cluster中应用的几种实现方式。","keywords":null,"kind":"page","lang":"en","lastmod":1511870400,"objectID":"62314fd01037305fcf6b8c9ad3b3b02d","permalink":"https://davidpaulyoung.com/2017/11/28/access-application-from-outside/","publishdate":"2017-11-28T12:00:00Z","readingtime":12,"relpermalink":"/2017/11/28/access-application-from-outside/","section":"post","tags":["Kubernetes"],"title":"如何从外部访问Kubernetes集群中的应用？","type":"post","url":"/2017/11/28/access-application-from-outside/","weight":0,"wordcount":5543},{"author":null,"categories":["Tech"],"content":"灰度发布（又名金丝雀发布）介绍 当应用上线以后，运维面临的一大挑战是如何能够在不影响已上线业务的情况下进行升级。做过产品的同学都清楚，不管在发布前做过多么完备的自动化和人工测试，在发布后都会出现或多或少的故障。根据墨菲定律，可能会出错的版本发布一定会出错。\n\u0026amp;ldquo;ANYTHING THAN CAN GO WRONG WILL GO WRONG\u0026amp;rdquo; \u0026amp;ndash;MURPHY\u0026amp;rsquo;S LAW\n因此我们不能寄希望于在线下测试时发现所有潜在故障。在无法百分百避免版本升级故障的情况下，需要通过一种方式进行可控的版本发布，把故障影响控制在可以接受的范围内，并可以快速回退。\n可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。\n“金丝雀发布”的来源于矿工们用金丝雀对矿井进行空气测试的做法。以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。\n下图中，左下方的少部分用户就被当作“金丝雀”来用于测试新上线的1.1版本。如果新版本出现问题，“金丝雀”们会报警，但不会影响其他用户业务的正常运行。 灰度发布（金丝雀发布）的流程如下：\n准备和生产环境隔离的“金丝雀”服务器。 将新版本的服务部署到“金丝雀”服务器上。 对“金丝雀”服务器上的服务进行自动化和人工测试。 测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。 如果在线测试出现问题，则通过把生产流量从“金丝雀”服务器中重新路由到老版本的服务的方式进行回退，修复问题后重新进行发布。 如果在线测试顺利，则逐渐把生产流量按一定策略逐渐导入到新版本服务器中。 待新版本服务稳定运行后，删除老版本服务。 Istio实现灰度发布(金丝雀发布)的原理 从上面的流程可以看到，如果要实现一套灰度发布的流程，需要应用程序和运维流程对该发布过程进行支持，工作量和难度的挑战是非常大的。虽然面对的问题类似，但每个企业或组织一般采用不同的私有化实现方案来进行灰度发布,为解决该问题导致研发和运维花费了大量的成本。\nIstio通过高度的抽象和良好的设计采用一致的方式解决了该问题，采用sidecar对应用流量进行了转发，通过Pilot …","date":1510153200,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":3300,"html":"当应用上线以后，运维面临的一大挑战是如何能在不影响已上线业务的情况下进行升级。本文将介绍如何使用Istio实现应用的灰度发布（金丝雀发布）","keywords":null,"kind":"page","lang":"en","lastmod":1510153200,"objectID":"320d9f0641802d90086c08b5cf554c4d","permalink":"https://davidpaulyoung.com/2017/11/08/istio-canary-release/","publishdate":"2017-11-08T15:00:00Z","readingtime":7,"relpermalink":"/2017/11/08/istio-canary-release/","section":"post","tags":["Istio"],"title":"采用Istio实现灰度发布(金丝雀发布)","type":"post","url":"/2017/11/08/istio-canary-release/","weight":0,"wordcount":3210},{"author":null,"categories":["Tech"],"content":"关于Istio的更多内容请参考istio中文文档。\n原文参见Traffic Shifting。\n本任务将演示如何将应用流量逐渐从旧版本的服务迁移到新版本。通过Istio，可以使用一系列不同权重的规则（10%，20%，··· 100%）将流量平缓地从旧版本服务迁移到新版本服务。\n为简单起见，本任务将采用两步将流量从reviews:v1 迁移到 reviews:v3，权重分别为50%，100%。\n开始之前 参照文档安装指南中的步骤安装Istio。\n部署BookInfo 示例应用程序。\n请注意：本文档假设示采用kubernetes部署示例应用程序。所有的示例命令行都采用规则yaml文件（例如samples/bookinfo/kube/route-rule-all-v1.yaml）指定的kubernetes版本。如果在不同的环境下运行本任务，请将kube修改为运行环境中相应的目录（例如，对基于Consul的运行环境，目录就是samples/bookinfo/consul/route-rule-all-v1.yaml）。\n基于权重的版本路由 将所有微服务的缺省版本设置为v1.\nistioctl create -f samples/bookinfo/kube/route-rule-all-v1.yaml 在浏览器中打开http://$GATEWAY_URL/productpage, 确认reviews 服务目前的活动版本是v1。\n可以看到浏览器中出现BooInfo应用的productpage页面。 注意productpage显示的评价内容不带星级。这是由于reviews:v1不会访问ratings服务。\n请注意：如果之前执行过 配置请求路由任务，则需要先注销测试用户“jason”或者删除之前单独为该用户创建的测试规则：\nistioctl delete routerule reviews-test-v2 首先，使用下面的命令把50%的流量从reviews:v1转移到reviews:v3:\nistioctl replace -f samples/bookinfo/kube/route-rule-reviews-50-v3.yaml 注意这里使用了istioctl replace而不是create。\n在浏览器中多次刷新productpage页面，大约有50%的几率会看到页面中出现带红 …","date":1510012800,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":1400,"html":"本任务将演示如何将应用流量逐渐从旧版本的服务迁移到新版本。通过Istio，可以使用一系列不同权重的规则（10%，20%，··· 100%）将流量平缓地从旧版本服务迁移到新版本服务。","keywords":null,"kind":"page","lang":"en","lastmod":1510012800,"objectID":"5ae8190e8b21dc18fae6ba6a26ad2f8e","permalink":"https://davidpaulyoung.com/2017/11/07/istio-traffic-shifting/","publishdate":"2017-11-07T00:00:00Z","readingtime":3,"relpermalink":"/2017/11/07/istio-traffic-shifting/","section":"post","tags":["Istio"],"title":"使用Istio实现应用流量转移","type":"post","url":"/2017/11/07/istio-traffic-shifting/","weight":0,"wordcount":1313},{"author":null,"categories":["Tech"],"content":"服务网格简介 服务网格（Service Mesh）是为解决微服务的通信和治理而出现的一种架构模式。\n服务网格将服务间通讯以及与此相关的管理控制功能从业务程序中下移到一个基础设施层，从而彻底隔离了业务逻辑和服务通讯两个关注点。采用服务网格后，应用开发者只需要关注并实现应用业务逻辑。服务之间的通信，包括服务发现，通讯的可靠性，通讯的安全性，服务路由等由服务网格层进行处理，并对应用程序透明。\n让我们来回顾一下微服务架构的发展过程。在出现服务网格之前，我们在微服务应用程序进程内处理服务通讯逻辑，包括服务发现，熔断，重试，超时等逻辑，如下图所示：\n通过对这部分负责服务通讯的逻辑进行抽象和归纳，可以形成一个代码库供应用程序调用。但应用程序还是需要处理和各种语言代码库的调用细节，并且各种代码库互不兼容，导致对应用程序使用的语言和代码框架有较大限制。\n如果我们更进一步，将这部分逻辑从应用程序进程中抽取出来，作为一个单独的进程进行部署，并将其作为服务间的通信代理，如下图所示：\n因为通讯代理进程和应用进程一起部署，因此形象地把这种部署方式称为“sidecar”（三轮摩托的挎斗）。 应用间的所有流量都需要经过代理，由于代理以sidecar方式和应用部署在同一台主机上，应用和代理之间的通讯被认为是可靠的。然后由代理来负责找到目的服务并负责通讯的可靠性和安全等问题。\n当服务大量部署时，随着服务部署的sidecar代理之间的连接形成了一个如下图所示的网格，被称之为Service Mesh（服务网格），从而得出如下的服务网格定义。\n服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。\n_William Morgan WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE? _\n了解了服务网格的基本概念，下一步介绍一下Istio。Istio是来自Google，IBM和Lyft的一个Service Mesh（服务网格）开源项目，是Google继Kubernetes之后的又一大作，Istio架构先进，设计合理，刚一宣布就获得了Linkerd，nginmesh等其他Service …","date":1509796800,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":5600,"html":"Istio是来自Google，IBM和Lyft的一个Service Mesh（服务网格）开源项目，是Google继Kubernetes之后的又一大作,本文将演示如何从裸机开始从零搭建Istio及Bookinfo示例程序。","keywords":null,"kind":"page","lang":"en","lastmod":1509796800,"objectID":"d993f98f09d7341809e97a3c1ba8e960","permalink":"https://davidpaulyoung.com/2017/11/04/istio-install_and_example/","publishdate":"2017-11-04T12:00:00Z","readingtime":12,"relpermalink":"/2017/11/04/istio-install_and_example/","section":"post","tags":["Istio"],"title":"Istio及Bookinfo示例程序安装试用笔记","type":"post","url":"/2017/11/04/istio-install_and_example/","weight":0,"wordcount":5529},{"author":null,"categories":null,"content":" “Yeah It\u0026amp;rsquo;s on. ”\nHello World! ","date":1509753600,"dir":"post/","expirydate":-62135596800,"fuzzywordcount":100,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":1509753600,"objectID":"cf37d97d83d29e7c3f79c50c928a7a4d","permalink":"https://davidpaulyoung.com/2017/11/03/hello-world/","publishdate":"2017-11-04T00:00:00Z","readingtime":1,"relpermalink":"/2017/11/03/hello-world/","section":"post","tags":null,"title":"Welcome to Zhaohuabing Blog","type":"post","url":"/2017/11/03/hello-world/","weight":0,"wordcount":10},{"author":null,"categories":null,"content":"About Me Huabing Zhao is a software architect, an Istio Member and an ONAP PTL. He has a solid experience in the information and telecommunication technology industry for more than 17 years.\nThroughout his career, he has built a number of large-scale, cross-country software systems, most of them are still running in production.\nHe loves open source and has been contributing to various open source projects, he is a member of Istio, previous PTL of ONAP, the author of the Hugo clean-white theme and the open source project Aeraki Mesh.\nHe also has strong interests in various technical topics such as Cloud Native, Artificial Intelligence, Cryptocurrencies, Smart Home, etc. He love sharing his ideas about these things in his blog.\nHuabing holds a BSc in Computer Science and Technology from Chongqing University in China.\nCurrently, Huabing works as a senior engineer at Tencent Cloud and also wears the hat of PTL in ONAP open source project. For now, his main focus is to build a managed …","date":-62135596800,"dir":"about/","expirydate":-62135596800,"fuzzywordcount":600,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"8576ec274c98b3831668a172fa632d80","permalink":"https://davidpaulyoung.com/about/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/about/","section":"","tags":null,"title":"","type":"page","url":"/about/","weight":0,"wordcount":500},{"author":null,"categories":null,"content":"Go 语言学习笔记 Envoy 学习笔记 ","date":-62135596800,"dir":"notes/","expirydate":-62135596800,"fuzzywordcount":100,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"1ede8046f9c3a02d422dea7bbf324e64","permalink":"https://davidpaulyoung.com/notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/notes/","section":"","tags":null,"title":"","type":"page","url":"/notes/","weight":0,"wordcount":12},{"author":null,"categories":null,"content":"","date":-62135596800,"dir":"search/","expirydate":-62135596800,"fuzzywordcount":100,"html":null,"keywords":null,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"8946788897930c0c0c39fbfcd30ff2e4","permalink":"https://davidpaulyoung.com/search/placeholder/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/search/placeholder/","section":"search","tags":null,"title":"","type":"search","url":"/search/placeholder/","weight":0,"wordcount":0},{"author":null,"categories":null,"content":"","date":-62135596800,"dir":"archive/","expirydate":-62135596800,"fuzzywordcount":100,"html":"Archive of historical posts.","keywords":null,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"a06e5ce9eca4c3260843078104889780","permalink":"https://davidpaulyoung.com/archive/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/archive/","section":"","tags":null,"title":"Posts Archive","type":"archive","url":"/archive/","weight":0,"wordcount":0}] |