first commits
This commit is contained in:
David Young
124
public/categories/tech/index.xml
Normal file
124
public/categories/tech/index.xml
Normal file
@@ -0,0 +1,124 @@
|
||||
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
|
||||
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
||||
<channel>
|
||||
<title>Tech on David Young</title>
|
||||
<link>http://localhost:1313/categories/tech/</link>
|
||||
<description>Recent content in Tech on David Young</description>
|
||||
<generator>Hugo</generator>
|
||||
<language>en-us</language>
|
||||
<lastBuildDate>Mon, 04 Jun 2018 00:00:00 +0000</lastBuildDate>
|
||||
<atom:link href="http://localhost:1313/categories/tech/index.xml" rel="self" type="application/rss+xml" />
|
||||
<item>
|
||||
<title>Istio v1aplha3 routing API介绍(译文）</title>
|
||||
<link>http://localhost:1313/2018/06/04/introducing-the-istio-v1alpha3-routing-api/</link>
|
||||
<pubDate>Mon, 04 Jun 2018 00:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/06/04/introducing-the-istio-v1alpha3-routing-api/</guid>
|
||||
<description><p>到目前为止，Istio提供了一个简单的API来进行流量管理，该API包括了四种资源：RouteRule，DestinationPolicy，EgressRule和Ingress（直接使用了Kubernets的Ingress资源）。借助此API，用户可以轻松管理Istio服务网格中的流量。该API允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等等，所有这些功能都不必更改应用程序本身的代码。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>Istio 0.8 Release发布</title>
|
||||
<link>http://localhost:1313/2018/06/02/istio08/</link>
|
||||
<pubDate>Sat, 02 Jun 2018 00:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/06/02/istio08/</guid>
|
||||
<description><blockquote>
<p>在6月1日这一天的早上，Istio社区宣布发布0.8 Release，除了常规的故障修复和性能改进外，这个儿童节礼物里面还有什么值得期待内容呢？让我们来看一看：</p>
</blockquote></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>微服务安全沉思录之三</title>
|
||||
<link>http://localhost:1313/2018/05/23/external_system_auth/</link>
|
||||
<pubDate>Wed, 23 May 2018 18:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/05/23/external_system_auth/</guid>
|
||||
<description><h2 id="外部系统访问控制">外部系统访问控制</h2>
<p>除用户访问和微服务之间的相互访问外，外部的第三方系统也可能需要访问系统内部的微服务。例如在上一篇博客的网上商店例子中，外部的推荐服务可能需要接入系统，以获取商店的商品目录信息。相对于内部服务之间的访问而言，外部系统的访问需要进行严格的安全控制。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>微服务安全沉思录之二</title>
|
||||
<link>http://localhost:1313/2018/05/23/service_2_service_auth/</link>
|
||||
<pubDate>Wed, 23 May 2018 15:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/05/23/service_2_service_auth/</guid>
|
||||
<description><h2 id="服务间认证与鉴权">服务间认证与鉴权</h2>
<p>除来自用户的访问请求以外，微服务应用中的各个微服务相互之间还有大量的访问，包括下述场景：</p>
<ul>
<li>用户间接触发的微服务之间的相互访问<BR>
例如在一个网上商店应用中，用户访问购物车微服务进行结算时，购物车微服务可能需要访问用户评级微服务获取用户的会员级别，以得到用户可以享受购物折扣。</li>
<li>非用户触发的微服务之间的相互访问<BR>
例如数据同步或者后台定时任务导致的微服务之间的相互访问。</li>
</ul>
<p>根据应用系统的数据敏感程度的不同，对于系统内微服务的相互访问可能有不同的安全要求。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>微服务安全沉思录之一</title>
|
||||
<link>http://localhost:1313/2018/05/22/user_authentication_authorization/</link>
|
||||
<pubDate>Wed, 23 May 2018 10:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/05/22/user_authentication_authorization/</guid>
|
||||
<description><blockquote>
<p>这段时间对之前微服务安全相关的一些想法进行了进一步总结和归纳，理清了在之前文章里面没有想得太清楚的地方，例如服务间的认证与鉴权以及用户身份在服务调用链中的传递。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>Istio Sidecar自动注入原理</title>
|
||||
<link>http://localhost:1313/2018/05/23/istio-auto-injection-with-webhook/</link>
|
||||
<pubDate>Wed, 23 May 2018 00:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/05/23/istio-auto-injection-with-webhook/</guid>
|
||||
<description><h2 id="前言">前言</h2>
<hr>
<p>Kubernets 1.9版本引入了Admission Webhook(web 回调)扩展机制，通过Webhook,开发者可以非常灵活地对Kubernets API Server的功能进行扩展，在API Server创建资源时对资源进行验证或者修改。</p>
<p>使用webhook的优势是不需要对API Server的源码进行修改和重新编译就可以扩展其功能。插入的逻辑实现为一个独立的web进程，通过参数方式传入到kubernets中，由kubernets在进行自身逻辑处理时对扩展逻辑进行回调。</p>
<p>Istio 0.7版本就利用了Kubernets webhook实现了sidecar的自动注入。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>使用Algolia为Gitpage博客提供站内搜索</title>
|
||||
<link>http://localhost:1313/2018/05/21/algolia-integration-with-jekyll/</link>
|
||||
<pubDate>Mon, 21 May 2018 11:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/05/21/algolia-integration-with-jekyll/</guid>
|
||||
<description><blockquote>
<p>This series of articles are my notes of &ldquo;Bitcoin and Cryptocurrency Technologies&rdquo; online course.</p>
</blockquote>
<h2 id="table-of-content">Table of Content</h2>
<p>{:.no_toc}</p>
<ul>
<li>Table of Content
{:toc}</li>
</ul>
<h2 id="scrooge-coin-transaction">Scrooge Coin Transaction</h2>
<p>Scrooge Coin programming assignment is a little bit tricky, the video of this lesson hasn&rsquo;t explained some implementation details. To help you understand the transaction data structure used in Scrooge Coin, I draw this diagram:

 <img src="http://localhost:1313/img/2018-5-20-cryptocurrency_week1_scroogecoin/scroogecoin.png" alt="Scrooge Coin">

</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>Helm介绍</title>
|
||||
<link>http://localhost:1313/2018/04/16/using-helm-to-deploy-to-kubernetes/</link>
|
||||
<pubDate>Mon, 16 Apr 2018 15:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/04/16/using-helm-to-deploy-to-kubernetes/</guid>
|
||||
<description><h2 id="前言">前言</h2>
<hr>
<p>Helm是Kubernetes生态系统中的一个软件包管理工具。本文将介绍为何要使用Helm进行Kubernetes软件包管理，澄清Helm中使用到的相关概念，并通过一个具体的示例学习如何使用Helm打包，分发，安装，升级及回退Kubernetes应用。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>Service Mesh 和 API Gateway的关系探讨（译文）</title>
|
||||
<link>http://localhost:1313/2018/04/11/service-mesh-vs-api-gateway/</link>
|
||||
<pubDate>Wed, 11 Apr 2018 09:32:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/04/11/service-mesh-vs-api-gateway/</guid>
|
||||
<description><h2 id="service-mesh-vs-api-gateway">Service Mesh vs API Gateway</h2>
<p>在<a href="https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a">前一篇关于Service Mesh的文章</a>中,我提到了几个关于Service Mesh和API Gateway之间关系的问题，在本篇文章中，我打算就Service Mesh和API Gateway的用途进行进一步讨论。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>谈谈微服务架构中的基础设施：Service Mesh与Istio</title>
|
||||
<link>http://localhost:1313/2018/03/29/what-is-service-mesh-and-istio/</link>
|
||||
<pubDate>Thu, 29 Mar 2018 12:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/03/29/what-is-service-mesh-and-istio/</guid>
|
||||
<description><h2 id="微服务架构的演进">微服务架构的演进</h2>
<p>作为一种架构模式，微服务将复杂系统切分为数十乃至上百个小服务，每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改，并带来了语言和框架选择灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。</p>
<p>另一方面，当应用被拆分为多个微服务进程后，进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>如何构建安全的微服务应用？</title>
|
||||
<link>http://localhost:1313/2018/05/22/user_authentication_authorization/</link>
|
||||
<pubDate>Sat, 03 Feb 2018 12:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/05/22/user_authentication_authorization/</guid>
|
||||
<description><h2 id="前言">前言</h2>
<p>微服务架构的引入为软件应用带来了诸多好处：包括小开发团队，缩短开发周期，语言选择灵活性，增强服务伸缩能力等。与此同时，也引入了分布式系统的诸多复杂问题。其中一个挑战就是如何在微服务架构中实现一个灵活，安全，高效的认证和鉴权方案。本文将尝试就此问题进行一次比较完整的探讨。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>Nginx开源Service Mesh组件Nginmesh安装指南</title>
|
||||
<link>http://localhost:1313/2018/01/02/nginmesh-install/</link>
|
||||
<pubDate>Tue, 02 Jan 2018 12:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2018/01/02/nginmesh-install/</guid>
|
||||
<description><h2 id="前言">前言</h2>
<p>Nginmesh是NGINX的Service Mesh开源项目，用于Istio服务网格平台中的数据面代理。它旨在提供七层负载均衡和服务路由功能，与Istio集成作为sidecar部署，并将以“标准，可靠和安全的方式”使得服务间通信更容易。Nginmesh在今年底已经连续发布了0.2和0.3版本，提供了服务发现，请求转发，路由规则，性能指标收集等功能。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>如何从外部访问Kubernetes集群中的应用？</title>
|
||||
<link>http://localhost:1313/2017/11/28/access-application-from-outside/</link>
|
||||
<pubDate>Tue, 28 Nov 2017 12:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2017/11/28/access-application-from-outside/</guid>
|
||||
<description><h2 id="前言">前言</h2>
<p>我们知道，kubernetes的Cluster Network属于私有网络，只能在cluster Network内部才能访问部署的应用，那如何才能将Kubernetes集群中的应用暴露到外部网络，为外部用户提供服务呢？本文探讨了从外部网络访问kubernetes cluster中应用的几种实现方式。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>采用Istio实现灰度发布(金丝雀发布)</title>
|
||||
<link>http://localhost:1313/2017/11/08/istio-canary-release/</link>
|
||||
<pubDate>Wed, 08 Nov 2017 15:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2017/11/08/istio-canary-release/</guid>
|
||||
<description><h2 id="灰度发布又名金丝雀发布介绍">灰度发布（又名金丝雀发布）介绍</h2>
<p>当应用上线以后，运维面临的一大挑战是如何能够在不影响已上线业务的情况下进行升级。做过产品的同学都清楚，不管在发布前做过多么完备的自动化和人工测试，在发布后都会出现或多或少的故障。根据墨菲定律，可能会出错的版本发布一定会出错。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>使用Istio实现应用流量转移</title>
|
||||
<link>http://localhost:1313/2017/11/07/istio-traffic-shifting/</link>
|
||||
<pubDate>Tue, 07 Nov 2017 00:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2017/11/07/istio-traffic-shifting/</guid>
|
||||
<description><p>关于Istio的更多内容请参考<a href="http://istio.doczh.cn/">istio中文文档</a>。</p>
<p>原文参见<a href="https://istio.io/docs/tasks/traffic-management/traffic-shifting.html">Traffic Shifting</a>。</p>
<p>本任务将演示如何将应用流量逐渐从旧版本的服务迁移到新版本。通过Istio，可以使用一系列不同权重的规则（10%，20%，··· 100%）将流量平缓地从旧版本服务迁移到新版本服务。</p></description>
|
||||
</item>
|
||||
<item>
|
||||
<title>Istio及Bookinfo示例程序安装试用笔记</title>
|
||||
<link>http://localhost:1313/2017/11/04/istio-install_and_example/</link>
|
||||
<pubDate>Sat, 04 Nov 2017 12:00:00 +0000</pubDate>
|
||||
<guid>http://localhost:1313/2017/11/04/istio-install_and_example/</guid>
|
||||
<description><h2 id="服务网格简介">服务网格简介</h2>
<p><strong>服务网格</strong>（Service Mesh）是为解决微服务的通信和治理而出现的一种<strong>架构模式</strong>。</p>
<p>服务网格将服务间通讯以及与此相关的管理控制功能从业务程序中下移到一个基础设施层，从而彻底隔离了业务逻辑和服务通讯两个关注点。采用服务网格后，应用开发者只需要关注并实现应用业务逻辑。服务之间的通信，包括服务发现，通讯的可靠性，通讯的安全性，服务路由等由服务网格层进行处理，并对应用程序透明。</p></description>
|
||||
</item>
|
||||
</channel>
|
||||
</rss>
|
||||
Reference in New Issue
Block a user