atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://blog.zhuxingzhao.com</id>
    <title>诸天域</title>
    <updated>2022-08-28T13:07:10.796Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <link rel="alternate" href="https://blog.zhuxingzhao.com"/>
    <link rel="self" href="https://blog.zhuxingzhao.com/atom.xml"/>
    <subtitle>温故而知新</subtitle>
    <logo>https://blog.zhuxingzhao.com/images/avatar.png</logo>
    <icon>https://blog.zhuxingzhao.com/favicon.ico</icon>
    <rights>All rights reserved 2022, 诸天域</rights>
    <entry>
        <title type="html"><![CDATA[基于Opentelemetry标准化的产品应用]]></title>
        <id>https://blog.zhuxingzhao.com/post/ji-yu-opentelemetry-biao-zhun-hua-de-chan-pin-ying-yong/</id>
        <link href="https://blog.zhuxingzhao.com/post/ji-yu-opentelemetry-biao-zhun-hua-de-chan-pin-ying-yong/">
        </link>
        <updated>2022-07-28T12:21:32.000Z</updated>
        <content type="html"><![CDATA[<h1 id="基于opentelemetry标准化的产品应用">基于Opentelemetry标准化的产品应用</h1>
<p>otel项目作为旨在解决可观测数据采集的最终标准化解决方案，数据的字段定义约定也是其落地的目标，这关系到后端观测系统的产品能力的衍生和发展。也是未来规范在不同的场景有着一致性的约束，对比与数据协议本身也是有着非常重要的作用。</p>
<h2 id="otel语义标准化的字段定义">otel语义标准化的字段定义</h2>
<blockquote>
<p><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/semantic_conventions/README.md">semantic_conventions</a><br>
<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/README.md">Resource</a><br>
<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/README.md">Trace</a><br>
<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/README.md">Metric</a></p>
</blockquote>
<p>上述三个链接是目前otel协议已经落地的相关标准化字段和标准化定义的相关规范，也就是说所有的otel相关的落地使用我们都应该遵守这个规范。这些标准化的字段规范有哪些内容。</p>
<ul>
<li>定义了不同场景下的该怎么命名字段。</li>
<li>定义了不同场景下我们应该怎么去设置我们的span或者metric的内容。<br>
我们从三个场景的例子来看看这些定义都有什么</li>
</ul>
<h3 id="resource">Resource</h3>
<p>Resouce在otel里面是一个全局的通用标签，也就是说，这个内容一般对于一个服务来说都是一致的。生意在Resource里面我们一般定义了以下的标准化字段</p>
<ul>
<li>服务的字段定义<br>
这个定义就可以帮助我们的后段系统通过一下的字段，知道服务有哪些，以及服务的租户、实例和版本等。</li>
</ul>
<table>
<thead>
<tr>
<th>Attribute</th>
<th>Type</th>
<th>Description</th>
<th>Examples</th>
<th>Requirement Level</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>service.name</code></td>
<td>string</td>
<td>Logical name of the service. [1]</td>
<td><code>shoppingcart</code></td>
<td>Required</td>
</tr>
<tr>
<td><code>service.namespace</code></td>
<td>string</td>
<td>A namespace for <code>service.name</code>. [2]</td>
<td><code>Shop</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>service.instance.id</code></td>
<td>string</td>
<td>The string ID of the service instance. [3]</td>
<td><code>627cc493-f310-47de-96bd-71410b7dec09</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>service.version</code></td>
<td>string</td>
<td>The version string of the service API or implementation.</td>
<td><code>2.0.0</code></td>
<td>Recommended</td>
</tr>
</tbody>
</table>
<ul>
<li>SDK的字段定义
<ul>
<li>例如<code>telemetry.sdk.name</code>就可以表示访问所使用的sdk的名字，因为我们服务所使用的sdk不一定的otel官方的sdk也可以是用户自研或者jager等开源sdk，这样我们就可以较好的了解sdk的使用情况。</li>
</ul>
</li>
<li>环境的字段定义
<ul>
<li>操作系统</li>
<li>社保</li>
<li>云厂商</li>
<li>部署方式</li>
<li>浏览器</li>
</ul>
</li>
</ul>
<h3 id="trace">Trace</h3>
<p>trace的规范一般是在使用traceSDK的使用需要记录一些我们相关埋点的一些信息。<br>
比如我们要记录ip的时候要怎么命名呢？是ip,inner_ip,ipv4,ipv6呢？<br>
如果是发生调用的时候怎么区别是本机的ip还是对端的ip呢。</p>
<p>这个规范定义就帮我们做到了这些。</p>
<p>Trace的标准规范就建议我们网络相关的使用<code>net.*.name</code>的命名方式，并且已经将常用的定义以及规范了下来。<br>
比如ip的定义就是<code>net.host.ip</code>OR<code>net.peer.ip</code>分别表示本机的ip和对端的ip，我们也看到了我们使用<code>net.host.*</code>来表示本机的网络信息定义，<code>net.peer.*</code>来表示对方的网络信息定义，这样也就方便我们在数据分析的时候做到相关的关联分析。</p>
<table>
<thead>
<tr>
<th>Attribute</th>
<th>Type</th>
<th>Description</th>
<th>Examples</th>
<th>Requirement Level</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>net.transport</code></td>
<td>string</td>
<td>Transport protocol used. See note below.</td>
<td><code>ip_tcp</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.app.protocol.name</code></td>
<td>string</td>
<td>Application layer protocol used. The value SHOULD be normalized to lowercase.</td>
<td><code>amqp</code>; <code>http</code>; <code>mqtt</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.app.protocol.version</code></td>
<td>string</td>
<td>Version of the application layer protocol used. See note below. [1]</td>
<td><code>3.1.1</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.peer.ip</code></td>
<td>string</td>
<td>Remote address of the peer (dotted decimal for IPv4 or <a href="https://tools.ietf.org/html/rfc5952">RFC5952</a> for IPv6)</td>
<td><code>127.0.0.1</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.peer.port</code></td>
<td>int</td>
<td>Remote port number.</td>
<td><code>80</code>; <code>8080</code>; <code>443</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.peer.name</code></td>
<td>string</td>
<td>Remote hostname or similar, see note below. [2]</td>
<td><code>example.com</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.host.ip</code></td>
<td>string</td>
<td>Like <code>net.peer.ip</code> but for the host IP. Useful in case of a multi-IP host.</td>
<td><code>192.168.0.1</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.host.port</code></td>
<td>int</td>
<td>Like <code>net.peer.port</code> but for the host port.</td>
<td><code>35555</code></td>
<td>Recommended</td>
</tr>
<tr>
<td><code>net.host.name</code></td>
<td>string</td>
<td>Local hostname or similar, see note below.</td>
<td><code>localhost</code></td>
<td>Recommended</td>
</tr>
</tbody>
</table>
<p>我们以网络相关的规范字段定义来了解了Trace相关的定义其他的可以自行前往对应的文档地址查看。</p>
<h3 id="metric">Metric</h3>
<blockquote>
<p><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/README.md">Metric</a><br>
Metric跟前两者不同的是，这里不仅有字段规范的定义，也有着指标名称的命名以及单位的规范建议。</p>
</blockquote>
<h4 id="命名规范">命名规范</h4>
<ul>
<li>limit 上限/总量<br>
用来表示恒定，已知的指标对象应该叫做<code>entity.limit</code>, 例如<code>system.memory.limit</code>表示系统的内存总量</li>
<li>usage 使用量<br>
用来表示恒定的目标对象的使用量的指标对象应该叫做<code>entity.usage</code>, 例如<code>system.memory.usage</code>表示系统内存使用量</li>
<li>utilization 利用率<br>
个测量超出其限制的使用量的指标对象应该被叫做<code>entity.utilization</code>,例如<code>system.memory.utilisation</code>表示正在使用的内存部分. <code>utilization</code>应该在[0, 1]</li>
<li>time<br>
用来表示时间流逝的指标对象应该叫做<code>entity.time</code>m, 例如<code>system.cpu.time</code> 表示cpu的占用时间</li>
<li>io<br>
测量双向流动的指标对象应该叫做<code>enitry.io</code>, 例如<code>system.network.io</code></li>
<li>other<br>
如果不符合上述描述的目标，可以比较自由的命名例如<code>network.packets</code></li>
</ul>
<h2 id="产品形态应用">产品形态应用</h2>
<p>我们如何在相关的观测产品上利用这些标准化的约定呢。众所周知，我们有了标准的数据，就可以尽可能的互相关联，减少我们在解决问题的时候排查时间，甚至在建设监控大盘的时候，可以比较容易的通告标准化的定义，快速建设相关仪表。</p>
<h3 id="主机实例的产品关联">主机实例的产品关联</h3>
<blockquote>
<p>前置条件：主机性能数据 CMDB基础架构数据 网络性能数据</p>
</blockquote>
<p>我们已知在数据中含有相关的<code>ip</code>字段内容，我们即可以通过<code>ip</code>与主机性能数据进行关联。如果<code>CMDB</code>系统比较强大的话。我们甚至可以直接展示主机到目标机器的直接的网络拓扑情况，能很快的排查底层的网络状态。</p>
<ul>
<li>快速查看目标主机性能和调用方主机性能</li>
<li>查看主机之间的网络联通状态</li>
</ul>
<h3 id="容器实例级别的">容器实例级别的</h3>
<blockquote>
<p>前置条件：容器监控数据 容器基础数据</p>
</blockquote>
<p>我们可以知道标准字段已经存在了容器习惯的字段，但是需要我们的SDK去在应用部署到<code>docker</code>或者<code>k8s</code>上面的时候去获取到容器基础数据。这样我们就能在仪表中快速关联到相关容器性能</p>
<ul>
<li>快速查看相关联容器性能，k8s集群状态</li>
</ul>
<h3 id="db级别">DB级别</h3>
<p>标准字段的<code>DB</code>字段，可以让我们识别出对应的数据库实例，这样可以直接查看数据库性能数据，而且可以进行<code>sql</code>的深度分析，来进行我们更加业务程度的性能分析。</p>
<ul>
<li>数据库性能数据查看</li>
<li><code>sql</code>分析</li>
</ul>
<h3 id="指标标准">指标标准</h3>
<p>我们可以标准的指标命名做什么，一旦指标在某个场景固定下来了指标的命名方式，我们即可以认为这个数据的已经固定了下来，我们可以正对一类的指标<code>limit</code>去固定相关的仪表使用方式，告警策略，更固定的命名可以直接固定仪表以及告警策略，对于用户来说，减少了使用成本，开箱即用。不用理解特定场景的下的指标命名。</p>
<ul>
<li>固定仪表盘</li>
<li>固定告警策略</li>
</ul>
<p>以上我们介绍了基于<code>otel</code>标准化的一些产品上的应用，<code>otel</code>不仅在做协议标准，<code>SDK</code>, <code>collector</code>,还有这些数据标准化也是相当重要的落地，只要这些标准化了，我们才能在产品上有更多的想象空间，不然就会在落地的实现上造成更多的割裂。希望<code>otel</code>的标准化落地越来越好，也希望在<code>SDK</code>有更多的标准化使用，以及落地实践。我们该怎样基于标准化去使用<code>SDK</code>,也希望更多的观测产品的设计者和开发者深度了解标准才能更好的设计出更好使用的可观测统一的产品。</p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[ SRE的主要工作]]></title>
        <id>https://blog.zhuxingzhao.com/post/sre-de-zhu-yao-gong-zuo/</id>
        <link href="https://blog.zhuxingzhao.com/post/sre-de-zhu-yao-gong-zuo/">
        </link>
        <updated>2022-05-22T10:44:37.000Z</updated>
        <content type="html"><![CDATA[<h2 id="主体">主体</h2>
<h3 id="制定slis-slos-slas">制定SLIs、SLOs、SLAs</h3>
<p>SRE最好从整个软件研发周期的最开始去联合相关的干系人去制定相关的SLI，在未来软件进入生产之后，更好的提供一份比较科学严谨的SLO以及SLA，以及避免在可能在欠缺SLI的情况下导致我们不得不为相关的指标增加开放工作，而且SRE应该为研发团队宣导相关SLI的历练，让研发在实现功能的同时考虑功能相关的SLI数据的埋点上报。这需要我们跟研发团队保持良好的沟通和宣导。</p>
<h4 id="概念">概念</h4>
<ul>
<li>
<p>SLIs<br>
服务水平指标<br>
表示对服务能够稳定运行而定义的一些指标</p>
</li>
<li>
<p>SLOs<br>
服务协议目标<br>
基于SLI达到的能够稳定运行的目标或者范围</p>
</li>
<li>
<p>SLAs<br>
服务水平协议<br>
是跟用户或者客户承诺的服务的可靠情况 是一种协议 当达不到承诺的情况下应该做的事情</p>
</li>
</ul>
<h4 id="三者的关系">三者的关系</h4>
<figure data-type="image" tabindex="1"><img src="https://blog.zhuxingzhao.com/post-images/1653216368716.png" alt="" loading="lazy"></figure>
<h4 id="干系人">干系人</h4>
<table>
<thead>
<tr>
<th>类型</th>
<th>干系人</th>
</tr>
</thead>
<tbody>
<tr>
<td>SLIs</td>
<td>SRE、产品</td>
</tr>
<tr>
<td>SLOs</td>
<td>SRE、产品</td>
</tr>
<tr>
<td>SLAs</td>
<td>销售、消费者</td>
</tr>
</tbody>
</table>
<h3 id="可靠性-性能和弹性-饱和度-可观测性">可靠性、性能和弹性、饱和度、可观测性</h3>
<h4 id="可靠性">可靠性</h4>
<h5 id="服务时间">服务时间</h5>
<table>
<thead>
<tr>
<th>可用率%</th>
<th>每年宕机时间</th>
<th>每月宕机时间(30天计算)</th>
<th>每周宕机时间</th>
</tr>
</thead>
<tbody>
<tr>
<td>90%</td>
<td>36.5 days</td>
<td>72 hours</td>
<td>16.8 hours</td>
</tr>
<tr>
<td>95%</td>
<td>18.25 days</td>
<td>36 hours</td>
<td>8.4 hours</td>
</tr>
<tr>
<td>98%</td>
<td>7.30 days</td>
<td>14.4 hours</td>
<td>3.36 hours</td>
</tr>
<tr>
<td>99%</td>
<td>3.65 days</td>
<td>7.20 hours</td>
<td>1.68 hours</td>
</tr>
<tr>
<td>99.5%</td>
<td>1.83 days</td>
<td>3.60 hours</td>
<td>50.4 minutes</td>
</tr>
<tr>
<td>99.8%</td>
<td>17.52 hours</td>
<td>86.23 minutes</td>
<td>20.16 minutes</td>
</tr>
<tr>
<td>99.9%</td>
<td>8.76 hours</td>
<td>43.2 minutes</td>
<td>10.1 minutes</td>
</tr>
<tr>
<td>99.95%</td>
<td>4.38 hours</td>
<td>21.56 minutes</td>
<td>5.04 minutes</td>
</tr>
<tr>
<td>99.99%</td>
<td>52.6 minutes</td>
<td>4.32 minutes</td>
<td>1.01 minutes</td>
</tr>
<tr>
<td>99.999%</td>
<td>5.26 minutes</td>
<td>25.9 seconds</td>
<td>6.05 seconds</td>
</tr>
<tr>
<td>99.9999%</td>
<td>31.5 seconds</td>
<td>2.59 seconds</td>
<td>0.605 seconds</td>
</tr>
</tbody>
</table>
<h5 id="mttr">MTTR</h5>
<p>MTTR 是设备从任何故障中恢复所需的平均时间。</p>
<h5 id="mtbf">MTBF</h5>
<p>MTBF 是在正常系统运行期间，机械或电子系统固有故障之间的预计经过时间。MTBF 可以计算为系统故障之间的算术平均（平均）时间。该术语用于可修复系统，而平均故障时间 (MTTF) 表示不可修复系统的预期故障时间。</p>
<h5 id="mttf">MTTF</h5>
<p>MTTF 表示不可修复系统的预期故障时间。</p>
<h4 id="性能和弹性">性能和弹性</h4>
<p>性能和弹性是两个冲突的点。如果我们一味的追求性能，必然导致我们的应用不是太弹性。如果太弹性也就意味着我们的应用性能不是那么强。<br>
这两者的取舍应该取绝于，我们的单体QPS以及用户的对于延迟的容忍度。</p>
<h4 id="饱和度">饱和度</h4>
<p>这个定义一般是定义我们的SLO，他可以是当前服务承载的容量，也可以是CPU使用率。饱和度最大值应该是我们服务不可用的时候的所表现的测量点。</p>
<h4 id="可观测性">可观测性</h4>
<p>我们系统的可观测性信号由以下四点</p>
<ul>
<li>指标</li>
<li>跟踪</li>
<li>日志</li>
<li>proile</li>
<li>crash</li>
</ul>
<p>这几个信号会帮助我们显著了解我们系统的稳定性，并能很好的帮助我们在故障的情况下，快速发现并且快速排障。<br>
而且这几个信号我们也应该进行数据标准的统一让几者可以关联起来，更好的帮助观察和故障排查。这也是现代可观测性建设的核心目标之一。<br>
我们应该建设一个具备相关信号的可观测性平台以及推动研发进行相关的可观测性信号能力的接入以及开发。<br>
最好联合相关团队进行宣导，以及最好有在迭代中有10%的人力投入能够做到相关的支持。</p>
<h5 id="指标">指标</h5>
<p>指标是一个很重要的概念，我们常常忽视他的存在。指标的定义，与监控系统所支持的数据模型结构，有着非常密切的关系。监控数据的来源，从数据的类型可以分为：数值，短文本字符串，日志(长文本字符串)。通常所讲的指标，都是对当前系统环境具有度量价值的统计数据，使我们能够明确知道当前系统环境的运行状态。<br>
指标的定义应该遵循SMART原则:</p>
<ul>
<li>S代表具体(Specific)  指标是明确的，有具体的含义，能反映具体的属性，有针对性的。</li>
<li>M代表可衡量(Measurable) 可测量指标的活动，包括百分比、数值等。</li>
<li>A代表可实现(Assignable) 能够将指标的值获取到，有技术手段或工具采集到。</li>
<li>R代表相关性(Realistic)  与其他指标在逻辑上存在一定关联性。</li>
<li>T代表有时限(Time-bound) 在一定的时间范围内取值跟踪。</li>
</ul>
<h5 id="指标数据模型openmetric">指标数据模型(OpenMetric)</h5>
<pre><code>metric_name{&lt;label name&gt;=&lt;label value&gt;, ...} value timestamp

node_disk_read_bytes_total{device=&quot;sr0&quot;} 4.3454464e+07
node_vmstat_pswpout 0
http_request_total{status=&quot;404&quot;, method=&quot;POST&quot;, route=&quot;/user&quot;} 94334
</code></pre>
<h5 id="指标类型">指标类型</h5>
<ul>
<li>Counter<br>
计数器是一种累计型的metric度量指标，它是一个只能递增的数值。计数器主要用于统计类似于服务请求数、任务完成数和错误出现次数这样的数据。</li>
<li>Gauge<br>
计量器表示一个既可以增加, 又可以减少的度量指标值。计量器主要用于测量类似于温度、内存使用量这样的瞬时数据。</li>
<li>Histogram<br>
直方图对观察结果（通常是请求持续时间或者响应大小这样的数据）进行采样，并在可配置的桶中对其进行统计。</li>
<li>Summary<br>
类似于直方图，汇总也对观察结果进行采样。除了可以统计采样值总和和总数，它还能够按分位数统计。</li>
</ul>
<h5 id="跟踪trace">跟踪（Trace)</h5>
<p>跟踪对于当下复杂的的分布式应用来说是非常必要的。它们可能分布在上千个服务器、不同的数据中心和可用区中，如何监控服务之间的依赖关系和调用链，以判断应用在哪个服务环节出了问题，哪些地方可以优化？<br>
当前最佳的分布式Trace协议选择应该是Opentelemetry</p>
<pre><code>Causal relationships between Spans in a single Trace

        [Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C is a `child` of Span A)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F]
</code></pre>
<pre><code>Temporal relationships between Spans in a single Trace

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–&gt; time

 [Span A···················································]
   [Span B··········································]
      [Span D······································]
    [Span C····················································]
         [Span E·······]        [Span F··]
</code></pre>
<h5 id="日志log">日志（Log)</h5>
<p>日志也是我们观察系统的一个重要信号，担心当今软件形势的发展，让我们的日志收集和存储受到了巨大的挑战。当我们的应用越来越多的从主机往k8s这种架构转型的时候，我们的日志采集受到了比较大的挑战，而且服务产生的日志也越来越多的，对于海量的日志的检索，我们需要探寻更多的方案。</p>
<h5 id="profile">Profile</h5>
<p>对于当下云原生的技术的发展，如何对云原生架构下的应用进行profile，也是我们的一个重要挑战，所幸的是由于bpf技术的相关发展，我们可以更好的利用底层技术，去快速的利用bfp相关的技术进行应用的profile从而帮助应用更好的调优。</p>
<h5 id="crash">Crash</h5>
<p>crash是我们线上环境出现问题之后的重要现场，我们理应建设好相关的crash分析流程，来更好的跟相关信号进行打通关联，从而跟好的做到自动化的问题发现，报告生成。</p>
<h3 id="错误预算">错误预算</h3>
<p>我们可以简单的用 <code>SLO目标 + 错误预算 = 100%</code> 来简单的计算出我们的错误预算。我们的一些日常工作例如版本迭代、变更、故障处理都算在错误预算里面，也就是只要会影响SLO的操作，都应该属于我们错误预算的一部分。如果我们超出了错误预算，也就意味着我们的SLA会收到用户质疑，也就意味着我们应该开始排查为啥错误预算的消耗过高，也就是我们应该给错误预算一个阈值范围，在一定范围的功能发布，变更操作都属于正常的，一旦超过某个值，也就意味着我们的系统可能出现了不稳定的情况，这个时候我们应该马上进行总结，寻找问题的原因，快速解决它。我们应该同真个团队寻找到一个合理的平衡点。</p>
<h3 id="事务工作预算">事务工作预算</h3>
<p>作为SRE，我们应该对工作有个要求:</p>
<ul>
<li>不需要人的地方由机器完成</li>
<li>需要的人的地方由机器辅助完成。<br>
所以需要人操作的地方一般属于我们的事务工作，但是我们也不需要将全部的时间投入到事务工作上，比如变更需要手工执行命令，手动的通知开放。这个时候我们应该理一理我们的时间投入情况，如果事务性的工作太多，是不是我们没有梳理好整个发布流程，变更流程。我们没有沉淀出相关的自动化流程。所以一旦发现我们的事务性工作占据太多的时间，一定要停下来梳理，哪些可以自动化的，哪些可以半自动化的。争取将人工参与的部分降到一个合理的地步。</li>
</ul>
<h3 id="风险识别和管理">风险识别和管理</h3>
<p>风险识别与管理，我在大学的时候学的是安全工程，这是一门专门学习如何进行风险识别与管理的学科，但是那都是对于现实层面的风险识别识别与管理，例如机械、工业、化学、交通等领域的，但都有着类似的方法论。<br>
说到风险，我们就要认识一下海恩法则</p>
<blockquote>
<p>海恩法则是德国飞机涡轮机的发明者德国人帕布斯·海恩提出一个在航空界关于飞行安全的法则,海恩法则指出: 每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。法则强调两点：一是事故的发生是量的积累的结果；二是再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。</p>
</blockquote>
<p>通过海恩法则，我们要认识到事前的风险识别与管理能极大的帮助我们避免相关问题的出现。所以需要我们对于应用架构有着极为深度的了解。并从可用性的角度，去判别应用风险的可能点。</p>
<ul>
<li>比如当容量过载的时候，系统可能出现什么问题。</li>
<li>机房断电，会出现什么问题</li>
<li>域名解析异常，会导致什么问题<br>
我们列出一份详尽的系统风险评估文档。从不同的角度列举不同风险的可能点以及事故预言。在现代云原生的发展下，我们更加可以利用混沌工程等故障去模拟相关风险的产生。</li>
</ul>
<h3 id="事故管理">事故管理</h3>
<p>事故是不可避免的，其实事故不可怕，可怕的是我们没有对事故进行总结学习。只有出现了事故，我们才能对于现有体系的问题进行修复总结，避免同一个事故再发生，所以我们需要对于事故有着细致的报告和总结复盘。</p>
<h3 id="事故报告事故复盘">事故报告&amp;事故复盘</h3>
<h4 id="事故报告">事故报告</h4>
<p>事故报告是我们了解事故全景的重要手段，我们需要通过事故报告了解到</p>
<ul>
<li>事故原因<br>
国内的朋友可以了解一下事故致因2-4模型</li>
<li>事故背景</li>
<li>事故半径</li>
<li>事故时间线</li>
<li>事故干系人</li>
<li>事故处理过程</li>
</ul>
<p>有了以上的信息，我们才可以详细的知道一个事故的全部面貌，最好我们有一个统一的知识库去存档这些，帮助以后我们了解相关的改进背景以及处理方案有着极好的作用。</p>
<h4 id="事故复盘">事故复盘</h4>
<p>研究故障或者失败的逻辑非常重要，复制成功者所做所为，不一定回让你成功，而避免失败者的做事套路，将一定会增加你的成功概率。</p>
<h5 id="底层逻辑">底层逻辑</h5>
<ul>
<li>故障是常态，无法完全避免</li>
<li>故障时表象，背后的技术和管理上的问题才是根因</li>
<li>可以包容失败，但是不允许犯错</li>
<li>个体的失误反而是一件好事</li>
</ul>
<p>良好的事故复盘能够有效的帮助团队，回顾整个事故的点线面，这样学习式的复盘，能更好的给每个人以比较深刻的印象，最好的是学习之后，能够整理出相关合理的流程帮助未来的事故不在发生以及推动相关工具建设，告警设置以及故障经验。</p>
<h2 id="项目研发工作">项目研发工作</h2>
<p>SRE还有重要的工作是相关系统的研发，因为很多重要平台都是通过sre孵化出来的，例如可观测系统、海量分布式作业平台，CMDB系统等。因为这些平台的使用才能更好的帮助整个团队提高研发效能水平。</p>
<h3 id="架构设计">架构设计</h3>
<p>SRE也需要有着相当不错的架构设计能力，因为sre需要评估研发团队的架构以及sre团队研发平台的架构，<br>
而且SRE也需要从架构层面去衡量整个系统的可靠性，可观测性等能力,并给出相关的指导意见。</p>
<h3 id="软件工程">软件工程</h3>
<p>软件工程更是SRE需要深入了解到，因为我们需要参与到研发流程的建设，不管是瀑布式的研发模式，还是现在DEVOPS敏捷迭代的开发模式，我们都应该完整的了解软件工程。</p>
<h3 id="项目管理">项目管理</h3>
<p>从我的经历来看，一般sre团队内部没有专职的项目管理的成员，所以一般需要某一个成员兼职项目管理的角色，这名成员一般要根据项目周期、时间风险、人力投入、技术分析、周边团队协作方面去规范项目进度。一般需要需要经验丰富的人担任。</p>
<h3 id="测试流程">测试流程</h3>
<p>sre自身的软件交付质量，也需要有相关的测试流程去把握，但是对于sre团队来说，最好是做到核心路径的单元测试覆盖，这样在重构或者功能迁移的时候，能快速回归测试迭代，最后通过完整的集成测试帮助上线前的交付验证，避免出现问题。</p>
<h3 id="研发流水线">研发流水线</h3>
<p>因为sre团队一般成员较少，所以自身的研发devops流水线一定要建设得比较好，才能高效的产出交付功能，不然就会陷入研发怪圈。<br>
所以产生了蓝鲸saas开发这种帮助快速开发的平台产品。</p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[技术运营的初入指南]]></title>
        <id>https://blog.zhuxingzhao.com/post/ji-zhu-yun-ying-de-chu-ru-zhi-nan/</id>
        <link href="https://blog.zhuxingzhao.com/post/ji-zhu-yun-ying-de-chu-ru-zhi-nan/">
        </link>
        <updated>2021-06-14T12:40:37.000Z</updated>
        <content type="html"><![CDATA[<blockquote>
<p>什么是技术运营，从字面上来说，就是使用利用技术做服务的人，或者是说直接能操作技术的人。他们不是开发，开发是创造技术的人，他们在工作中，可能是DBA，可能是运维，可能是SA。他们是上层的技术使用人员，他们不编码创造实际的技术，但是他们懂得维护，使用，规划，让技术能够被使用，服务于更上层的设施。随着时代的发展，技术运营也在不断的改变着，可能现在大家说云时代，云原生，技术运营是不是没用了，必然不是，只是技术的升级，让我们面向的技术发生了改变。我们必然要顺应的时代的潮流，构建新时代的技术运营之路。</p>
</blockquote>
<blockquote>
<p>本文只阐述业务运维的技术运营初入</p>
</blockquote>
<h1 id="技术运营之路的发展">技术运营之路的发展</h1>
<h2 id="谷歌sre-现代技术运营之路的圣经">谷歌SRE 现代技术运营之路的圣经</h2>
<p>谷歌SRE 讲述了谷歌到现在为止，是如何支持谷歌全球系统的模式和方法。让我们知道了在一个复杂系统的公司中，该如何去构建我们的技术运营之路。</p>
<p>谷歌SRE虽然详细的阐述了谷歌在技术运营道路上的探索和实践，但确是大部分公司不太能够复制的。</p>
<p>谷歌SRE有两种人员</p>
<ul>
<li>全职的开发人员</li>
<li>一半开发，一半负责运营事务的人员</li>
</ul>
<p>也就是说要构建和谷歌一样的技术运营体系，我们需要将现有的运维人员体系升级，改头换面。这需要付出比较大的成本。特别是中国国内公司大部分的技术运营部门，主要以运营事务为主，基本没有成体系的开发能力。难以构建出类似的SRE体系。</p>
<h2 id="为什么我们讲技术运营而不是技术运维">为什么我们讲技术运营而不是技术运维</h2>
<h4 id="两者的区别关键">两者的区别关键</h4>
<table>
<thead>
<tr>
<th style="text-align:center">运营</th>
<th style="text-align:center">运维</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center">主动的</td>
<td style="text-align:center">被动的</td>
</tr>
<tr>
<td style="text-align:center">长期可持续的</td>
<td style="text-align:center">短期不可持续</td>
</tr>
<tr>
<td style="text-align:center">积极前进</td>
<td style="text-align:center">稳定固守</td>
</tr>
<tr>
<td style="text-align:center">改进</td>
<td style="text-align:center">维护</td>
</tr>
</tbody>
</table>
<p>长期以来，传统运维一直有着右边的缺陷，因为大部分的运维部门一直是执行的角色，很难有主观性，</p>
<ul>
<li>按操作手册执行</li>
<li>不出事就行</li>
<li>固步自封</li>
<li>更新迭代缓慢</li>
</ul>
<p>长期的刻板印象，导致大部分人对这一领域存在偏见。</p>
<p>但是其实从谷歌SRE的输出来看，技术运营其实是公司长效运营的重要支撑领域， 我们可以更好的维护系统，以及如何做到更加稳定更加高效的持续运营之路。</p>
<p>所以我们更应该转换我们的思维方式，发挥我们的长处。从被动向主动，更加积极的从业务出发，发展迭代处于自己的技术运营之路。</p>
<ul>
<li>贴近业务</li>
<li>宏观上的了解</li>
<li>底层上的领悟</li>
</ul>
<h2 id="运维的时代挑战">运维的时代挑战</h2>
<p>每个时代都有各自时代的挑战。</p>
<h4 id="物理机时代">物理机时代</h4>
<p>其实我们的一开始的运维人员都是直接面对机器，操作的机器都是实体机器而去都是物理机器的时代，我们面临的就是</p>
<ul>
<li>利用率不高</li>
<li>难以合理自动化</li>
<li>机型差异大</li>
<li>需要关注硬件状态</li>
</ul>
<h4 id="虚拟机时代">虚拟机时代</h4>
<p>随着时代的发展，我们已经意识到物理机的缺陷，所以开始发展出了虚拟化技术，即一台物理机器可以运行多个操作系统，而且能够共享资源。这样就带来了</p>
<ul>
<li>利用率开始提高</li>
<li>需要关注不同虚拟化的差异</li>
</ul>
<h4 id="云计算时代">云计算时代</h4>
<p>云计算时代的目标，就是将我们的计算和存储做到按需使用，即水和电一样，用到多少，付费多少。单其实一开始的云计算目标，也还是我们虚拟化技术的发展导致的，我们将单机的虚拟化技术升级到集群，机房级别的虚拟机调度，创建，共享。</p>
<ul>
<li>按需使用</li>
<li>云上共享资源的问题</li>
<li>潜在的性能问题</li>
</ul>
<h4 id="云原生时代">云原生时代</h4>
<p>在云原生的时代，关注已经从机器资源脱离，我们需要面对更加抽象的目标 计算，存储，应用，发布模式也随着转变</p>
<ul>
<li>不在面向机器运维</li>
<li>面向更加抽象的目标 应用 容器 serverless等</li>
<li>声明式描述</li>
<li>不可变基础设施</li>
</ul>
<h1 id="技术运营运维之路的发展方向">技术运营（运维）之路的发展方向</h1>
<p>本章我们将阐述，技术运营在未来的发展方向。</p>
<h3 id="持续交付持续部署cd">持续交付&amp;持续部署（CD）</h3>
<p>这些工作其实一直是我们的核心工作，我们一般的流程就是开发构建交付产物之后，我们能够高效快速的部署到服务器上面。</p>
<h4 id="基于虚拟机物理机">基于虚拟机&amp;物理机</h4>
<p>基于虚机的交付方式，一般要求我们的构建产物为可执行的实际二进制等。我们需要将对应的产物分发到我们的目标机器上。然后进行批量的启动,<code>reload</code>, 或者重启等操作。或者就是向我们的目标客户交付我们包装过的安装包等。<br>
我们需要面对的是</p>
<ul>
<li>产物分发</li>
<li>配置管理以及下发</li>
<li>更新方式</li>
<li>进程管控</li>
<li>版本管理</li>
<li>流量控制</li>
</ul>
<h4 id="云原生时代的交付">云原生时代的交付</h4>
<p>云原生的交付，一般交付的产物就是容器镜像，以及对应的声明式配置。</p>
<ul>
<li>需要规范镜像tag的版本交付</li>
<li>云原生的发布方式</li>
</ul>
<h3 id="devops">DEVOPS</h3>
<p>DEVOPS是现在非常火的一个概念<br>
<img src="https://blog.zhuxingzhao.com/post-images/1623675990943.png" alt="" loading="lazy"><br>
以及上述我们所讲的谷歌SRE体系其实就是devops在谷歌的实践之路<br>
但是我们其实对DEVOPS一体化存在许多的理解</p>
<h4 id="devops左移">DEVOPS左移</h4>
<p>开发开始负责运维的工作，即团队内不存在运维，其实就是我们需要构建一个一体化的发布流程。我们只需要简单的推送代码，构建，灰度，点击发布，就ok，不在需要关注实际的机器。这个只存在于基础完全标准话的公司，有着标准的体系。</p>
<h4 id="devops右移">DEVOPS右移</h4>
<p>即运维开始开发，运维开始开发，就是做一些辅助性的系统，或者是工具，即我们在脱离繁琐的体力工作之后，我们就可以极高的提高沉淀我们的生产力</p>
<ul>
<li>作业系统</li>
<li>发布系统</li>
<li>代码检查</li>
<li>流程系统</li>
<li>等</li>
</ul>
<p>但是运维做开发，有一个前提，就是我们需要一个完善的paas平台帮助运维去快速构建应用系统，减轻心智负担，才能很好的做到运维向开发的转型。</p>
<h3 id="海量自动化">海量自动化</h3>
<p>海量自动化，其实该如何理解，其实就是我们拥有将工作当初所遇到繁琐，体力性的工作转变为自动化的能力，这是我们技术运营的核心能力之一。其实在AWS每年都有要求提高多少自动化的指标。</p>
<ul>
<li>不需要人的地方，机器完成</li>
<li>需要人的地方，用机器辅助人完成</li>
</ul>
<p>我们自动化的目标遵循以上原则。</p>
<p>不管我们面对什么样的流程，或者是工作形式，只要你能快速的去构建自动化的能力，那你就是非常流弊的存在。</p>
<h3 id="aidata-ops">AI&amp;DATA OPS</h3>
<p>我们运维人员，相对于其他的岗位来说，其实我们是非常贴近业务的，我们知道业务的核心指标，核心数据，而且我们又比数据分析人员，更加的懂相关的技术，所以我们能够去分析业务上的问题，给业务作出参考。</p>
<h4 id="aiops">AIOPS</h4>
<p>AIOPS是现在技术运营领域一大挑战，随着我们数据和基础的沉淀，我们可以利用相依的AI能力辅助我们的运营之路。</p>
<ul>
<li>智能监控
<ul>
<li>根因分析</li>
<li>指标异常检测</li>
</ul>
</li>
<li>日志聚类</li>
<li>智能预测</li>
<li>知识图谱<br>
但是AIOPS对于我们的技术运营人员来说，存在着门槛过高，难以落地的问题。</li>
</ul>
<h4 id="data-ops">DATA OPS</h4>
<p>数据运营，意味着我们需要从数据的场面出发，去探索数据当中存在的价值，实现要求的是我们的技术运营同学，需要很输入的了解业务，知道哪些数据是有价值的，然后提炼出来，在借助企业的数据平台的能力，输出沉淀到对应的可视化平台。需要学习相应的数据分析和大数据使用相关的能力。</p>
<h3 id="运营规划">运营规划</h3>
<p>运营规划其实是一个比较资深的发展方向，往这个方向发展，其实是需要你在这个领域长期不断的专研。<br>
- 运营流程规划<br>
- 运营标准规划<br>
- 基础运营平台规划<br>
- 基础成本核算<br>
- 项目管理</p>
<h1 id="云原生时代的技术运营挑战">云原生时代的技术运营挑战</h1>
<p>时代不断的发展，我们已经来到云原生时代的发展。我们的基础设施已经高度的抽象，我们技术架构，运行架构也必须适应这个时代发展。</p>
<h4 id="为什么上云">为什么上云</h4>
<p>上云的优势，已经很多文章都列举了，这里不在论述。这里我们需要关注的就是我们技术运营需要关注的为什么上云。</p>
<ul>
<li>成本上的考虑</li>
<li>不必要的裁撤成本</li>
<li>paas化的平台体系</li>
<li>弹性的资源</li>
<li>开箱可用</li>
</ul>
<h4 id="我们需要学习什么">我们需要学习什么</h4>
<ul>
<li>容器操作和管理</li>
<li>K8s知识</li>
<li>微服务理论基础知识</li>
<li>网络方案的选型</li>
<li>服务治理方案</li>
<li>持续交付理论及开发团队的工作流程，研发效能度量方法论</li>
</ul>
<h4 id="我们在云原生上面可以做什么">我们在云原生上面可以做什么</h4>
<h5 id="发布模式的转变">发布模式的转变</h5>
<p>我们从面向虚拟机的发布模式，需要转变为面相容器，面向应用的发布模式</p>
<ul>
<li>不在关注机器</li>
<li>不关注底层配置</li>
<li>只关注抽象资源</li>
<li>产物发生改变</li>
<li>更加的版本化</li>
</ul>
<h5 id="可观测性建设">可观测性建设</h5>
<p>可观测性三架马车</p>
<ul>
<li>日志</li>
<li>指标</li>
<li>分布式跟踪</li>
</ul>
<p>由于云原生时代，我们的关注点发生改变，我们不在上以前那种直接观察机器，机器上的二进制的方式，我们构建需要在云原生的可观测性方式。</p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[大中型游戏运维思考]]></title>
        <id>https://blog.zhuxingzhao.com/post/da-zhong-xing-you-xi-yun-wei-si-kao/</id>
        <link href="https://blog.zhuxingzhao.com/post/da-zhong-xing-you-xi-yun-wei-si-kao/">
        </link>
        <updated>2021-06-12T14:03:29.000Z</updated>
        <content type="html"><![CDATA[<blockquote>
<p>笔者从20年开始参与某大中型手游运维工作，以及在组内其他游戏运维经验的见解<br>
粗略描写，后续补充</p>
</blockquote>
<h2 id="叙述">叙述</h2>
<h2 id="游戏运维面对的挑战">游戏运维面对的挑战</h2>
<h3 id="架构复杂多样化">架构复杂多样化</h3>
<p>游戏架构大多架构复杂，为了应对海量的用户，架构上都是高度集群以及分布式</p>
<h3 id="模块数量多">模块数量多</h3>
<p>随着游戏生命周期的不断延续，其运营的过程中，会随着运营的发展不断增加模块来支持不同的玩法和活动，我所接触的某fps手游就多达100以上的游戏进程模块。</p>
<h3 id="发布频繁">发布频繁</h3>
<p>游戏运营过程中，必然随着运营所带来的各种活动和策划的玩法修改，必然会有不断的频繁的发布。这就要求运维必须有能力支持这种频繁的发布，特别是面对复杂游戏业务的时候。</p>
<h3 id="有状态过多">有状态过多</h3>
<p>游戏一般为了保障用户体验，大部门的游戏模块都是有状态设计，这就导致了不能像web应用可以使用大规模无状态应用的发布方式。对于有状态的应用的发布，必然慎之又慎，避免用户数据丢失导致的用户体验和用户投诉。</p>
<h3 id="不停机发布的挑战">不停机发布的挑战</h3>
<p>为了保障用户的良好体验，越来越多的游戏都开始建设了不停服发布的发布流程，就是为了保证玩家体验不中断。但是不停服就给游戏架构和运维带来了挑战，如何建设一个稳定的不停服发布流程是需要运维和开发需要不断沟通设计的。</p>
<h2 id="准备阶段">准备阶段</h2>
<p>本章阐述游戏的基础准备内容，运维人员应该在游戏正式发布之前建设好以下内容，在随着游戏运营的不断发展进行调整。</p>
<h3 id="机器资源容量评估">机器资源容量评估</h3>
<p>机器资源容量评估是一个非常重要的准备工作，我们对于容量评估必须保证合理以及冗余。</p>
<ul>
<li>模块数量</li>
<li>单模块承载容量</li>
<li>机器非游戏进程的以外其他进程的消耗</li>
<li>适量的冗余</li>
<li>我们必然保证模块从前往后应该逐渐冗余，上游模块压垮下游模块</li>
</ul>
<p>容量评估完成，必须沉淀为标准公式即</p>
<p>当前预计容量 / 单模块单机（需要明确机型）容量 = 机器数量</p>
<p>完成标准公式是为之后的标准化流程建设准备</p>
<h3 id="cdn容量评估">CDN容量评估</h3>
<p>CDN是游戏成本的大头，我们需要考虑每次发布所需要的CDN容量，来进行必要的容量准备，以及可以的成本优化。常见的成本优化方法</p>
<ul>
<li>预下载</li>
<li>边缘CDN</li>
<li>P2P下载</li>
</ul>
<h3 id="成本核算">成本核算</h3>
<p>运维需要对游戏消耗成本的高度敏感，我们需要了解游戏成本方方面面，明确占比，在必要的时候，需要进行成本优化，将不必要的成本优化掉，减少必要的浪费。</p>
<ul>
<li>CDN</li>
<li>机器成本</li>
<li>储存成本</li>
<li>营销机器成本</li>
</ul>
<h3 id="机器初始化准备">机器初始化准备</h3>
<p>我们需要梳理机器所必要的一些初始化的准备</p>
<ul>
<li>网络内核参数调优</li>
<li>运营目录结构</li>
<li>crontab定时作业</li>
<li>必要的非游戏进程（监控，管控，数据上报）</li>
</ul>
<h3 id="模块划分">模块划分</h3>
<p>我们需要按模块合理划分游戏进程，这一步一般需要和开发进行沟通考虑。运维侧最好有相关的元数据管理系统，沉淀模块信息。</p>
<h2 id="统一的基础设施建设">统一的基础设施建设</h2>
<p>一个统一的基础设施是非常有必要的，避免人员迭代以及不规范的一些操作导致线上环境不断发散腐烂。</p>
<h3 id="基于虚拟机或物理机器到运维基础设施建设">基于虚拟机或物理机器到运维基础设施建设</h3>
<h4 id="统一的机器镜像">统一的机器镜像</h4>
<p>我们最好事先准备一个统一的机器镜像，里面安装了必要的软件和去除不必要的东西。</p>
<h4 id="统一的脚本">统一的脚本</h4>
<p>我所见到很多老运维对于脚本管理简直是混乱不堪，线上存在许许多多的脚本，而不明确每个脚本的作用。我们必须建设统一的cli工具作为统一运维console工具的入口。虽然shell是运维的强大工具。在这里我推荐的是go来构建统一的cli工具。</p>
<ul>
<li>go直接打包成可执行二进制，不分散文件</li>
<li>静态语言的特性保证了工具的质量</li>
<li>不需要关心机器的运行环境</li>
</ul>
<p>统一的cli工具的优势</p>
<ul>
<li>唯一的操作入口</li>
<li>沉淀工具脚本</li>
<li>各个环境版本一致</li>
</ul>
<h4 id="统一的配置">统一的配置</h4>
<p>上面我们说了建设统一cli工具，那我们的环境配置也需要统一的配置，通过统一的环境配置，我们可以在不同的环境通过不同的环境配置就可以达到不同环境一个脚本一个操作，而不必不同环境单独书写不同的脚本。操作统一，避免事故。推荐yaml形式作为配置。</p>
<h4 id="版本化的管理">版本化的管理</h4>
<p>我们以上的统一的建设，都必须要做到一个要求，就是版本化的管理。我们可以使用版本管理软件将以上建设纳管。 我们就可以建设一套基础设施管理的流程。我们可以通过软件开发的方法保证我们的基础设施的质量。 我们遵循gitflow或者github flow的方式，来对我们的基础设施进行发布管理 然后通过CD工具自动发布到全部的机器，保证全部环境的统一。</p>
<h3 id="基于容器的基础设施建设">基于容器的基础设施建设</h3>
<p>随着业务上云的趋势。我们也在探索容器在游戏领域的探索。</p>
<h4 id="k8s集群的基础设施">k8s集群的基础设施</h4>
<p>首当其冲就是k8s集群的管理，这里建议的是最好是托管到各个云平台的容器服务，自建k8s集群需要投入必要的容器运维人员。</p>
<h4 id="helm配置管理">helm配置管理</h4>
<p>容器的配置管理自然是helm，我们需要根据游戏架构的设计，进行对应template的文件编写。</p>
<h2 id="流程管理">流程管理</h2>
<p>流程是一个游戏运营生命周期非常重要的一环，最好是有一个流程编排系统，并且打通相关的系统。方便我们进行流程的编排和自动化。 我们的要求是 - 不需要人的地方，由工具操作 - 需要人的地方，工具辅助人操作</p>
<h3 id="虚拟机或物理机">虚拟机或物理机</h3>
<h4 id="发布流程">发布流程</h4>
<p>一个完整的发布流程一般有以下部分</p>
<ul>
<li>当前版本容量评估阶段</li>
<li>机器准备阶段</li>
<li>机器初始化阶段</li>
<li>产物发布</li>
<li>进程发布</li>
<li>检查</li>
<li>发布完成</li>
</ul>
<h4 id="不停服发布">不停服发布</h4>
<p>不停服发布需要游戏架构支持，一般的不停服发布主要有以下方式</p>
<ul>
<li>
<p>两个版本两批机器</p>
<ul>
<li>发布不影响上一版本</li>
<li>需要版本发布期间需要两部容量的机器</li>
</ul>
</li>
<li>
<p>机器分批发布</p>
<ul>
<li>模块需要数量需要为2n以上，避免分批发布过程中，出现单点</li>
<li>需要架构支持玩家下线不在路由导向另一批机器</li>
<li>存在一定的用户体验影响，强制引导另外一批机器入口</li>
</ul>
</li>
</ul>
<h4 id="停机发布">停机发布</h4>
<p>停机发布只要遵循正常发布流程即可，需要运营侧发布正常的停机公告。</p>
<h4 id="容量调整">容量调整</h4>
<p>在游戏运营过程中，我们不可避免，某次活动导致玩家人数上升，需要扩容机器，某段时间玩家人数下降，导致缩容机器。</p>
<h4 id="扩容流程缩容流程">扩容流程&amp;缩容流程</h4>
<p>游戏进程一般分局内局外进程。所以正常的两块的机器是不一样的。</p>
<ul>
<li>
<p>扩容流程</p>
<ul>
<li>机器准备</li>
<li>分发对应游戏版本产物</li>
<li>启动进程</li>
<li>检查</li>
<li>扩容完成</li>
</ul>
</li>
<li>
<p>缩容</p>
<ul>
<li>等待玩家下线（需要进程支持配置模块不接受新玩家）</li>
<li>停止进程</li>
<li>检查</li>
<li>机器下线</li>
</ul>
</li>
</ul>
<h4 id="故障替换流程">故障替换流程</h4>
<ul>
<li>替换流程
<ul>
<li>新机器准备</li>
<li>分发对应游戏版本产物到新机器</li>
<li>启动进程</li>
<li>检查</li>
<li>切换</li>
<li>替换完成</li>
<li>下线故障机器</li>
</ul>
</li>
</ul>
<h2 id="可观测性建设">可观测性建设</h2>
<p>在游戏运营过程中，我们必须建设好业务的可观察性，避免故障发生，没有及时的发现，以及方便的排除各种问题。</p>
<h3 id="必要关键链路">必要关键链路</h3>
<ul>
<li>登录</li>
<li>注册</li>
<li>在线</li>
<li>付费</li>
<li>对局</li>
</ul>
<h3 id="指标">指标</h3>
<h4 id="业务指标">业务指标</h4>
<ul>
<li>在线指标</li>
<li>登录指标</li>
<li>注册指标</li>
<li>付费指标</li>
</ul>
<h4 id="机器指标">机器指标</h4>
<ul>
<li>cpu</li>
<li>内存</li>
<li>磁盘</li>
<li>网络</li>
</ul>
<h3 id="日志">日志</h3>
<p>需要建设必要的分布式日志系统，以及统一的日志规范。 可以基于ELK开源方案构建日志系统。 或者云厂商的日志方案</p>
<h3 id="分布式跟踪">分布式跟踪</h3>
<p>游戏模块后台链路复杂，最好游戏支持从客户端开始的分布式跟踪协议,这里建议的是opentelemetry ，最好支持染色机制，排查特定的链路问题。</p>
<h3 id="告警建设">告警建设</h3>
<p>建设好可观测相关的内容之后，我们就可以建设稳定的监控策略</p>
<ul>
<li>各种环境的策略</li>
<li>策略的干系人</li>
<li>策略的阈值</li>
<li>策略的对象 随着建设的不断完善，我们也可以建设智能监控相关的能力。</li>
</ul>
<h2 id="运维需要的相关工具">运维需要的相关工具</h2>
<ul>
<li>CMDB平台</li>
<li>作业系统</li>
<li>文件分发系统</li>
<li>版本管理系统</li>
<li>流程编排</li>
<li>可观察性平台</li>
<li>文档系统</li>
</ul>
<h2 id="游戏数据分析">游戏数据分析</h2>
<p>我们需要建设游戏领域的数据场景模型</p>
<ul>
<li>在线场景</li>
<li>登录场景</li>
<li>注册场景</li>
<li>付费场景</li>
<li>网络场景</li>
<li>客户端路径</li>
<li>服务端路径</li>
<li>游戏地图分析</li>
<li>客户端设备分析</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[领域驱动设计思考]]></title>
        <id>https://blog.zhuxingzhao.com/post/ling-yu-qu-dong-she-ji-si-kao/</id>
        <link href="https://blog.zhuxingzhao.com/post/ling-yu-qu-dong-she-ji-si-kao/">
        </link>
        <updated>2021-03-28T10:26:53.000Z</updated>
        <content type="html"><![CDATA[<h3 id="软件设计模式的发展">软件设计模式的发展</h3>
<p>软件设计模式一直在不断的发展和实践过程中，我们一直不断的总结和思考什么样的软件设计模式适合实际的项目开发。<br>
从上个世纪以来，从直接特定硬件上构建软件，到操作系统的诞生，我们的软件开发人员从此从繁琐的底层操作抽离出来，从而可以吧中心放到了实际功能的实现，让我们不在关注底层的细节。这正是操作系统所带来的。从而带来的思想是，我们可以通过分层去处理问题。<br>
<img src="https://blog.zhuxingzhao.com/post-images/1616927448754.jpg" alt="" loading="lazy"><br>
随之而来的带来带问题是，在不同的操作系统之间，我们的应用软件带来了互相不兼容的问题，我们的一份代码不能在这些不同的操作系统的之间实用，那怎么办呢，我们继续使用上面的思考办法，我们继续对操作系统进行隔离，我们构建一套虚拟机，来运行我们的代码。这就是<code>java</code>，它所宣称的思想就是一次编译，各个平台都能运行。<br>
所以分层的思想是一个相当重要的思想。当我们将复杂问题都给分层处理之后，随后在应用软件开发中，我们也随之面对着在应用软件开发中所遇到的问题，我们的软件架构也需要在这些问题中进行着设计。那么我们对实际问题对分析之后得出，在实际应用程序之中，我们对数据流转过程的分析，我们得出了一种新的软件设计模式，这就是<code>mvc</code>模式。<br>
<img src="https://blog.zhuxingzhao.com/post-images/1616927463569.jpg" alt="" loading="lazy"><br>
在面向用户的应用程序中，对其中的交互过程，抽象成了上图的方式，通过<code>controller</code>来处理逻辑，<code>model</code>来处理数据，<code>view</code>来展示，在<code>web</code>1.0的时代的时候，<code>view</code>层主要在后端处理，而在2.0的时代来临之后，在我们将<code>view</code>过渡到前端之后，后端天然的变成了<code>cm</code>模式了。<br>
随着时间的前进，我们继续探索者更加符合当代的软件设计模式，我们随之又提出了<code>mvvm</code>的开发方式<br>
<img src="https://blog.zhuxingzhao.com/post-images/1616927475525.jpg" alt="" loading="lazy"><br>
通过上述模型有助于将图形用户界面的开发与业务逻辑或后端逻辑（数据模型）的开发分离开来，前后端的人员明确的分工开始了。<br>
随着当代软件的复杂度和规模不断扩大，我们需要一些更加符合实际的设计模式来帮助我们完成我们的软件设计以达到良好的工程效率以及代码质量。<code>TDD</code>和<code>DDD</code>设计相继被实践出来。在<code>TDD</code>的方法下，我们在<code>红绿</code>重构之间不断完善我们的代码功能和逻辑以达到良好的项目质量。<br>
<img src="https://blog.zhuxingzhao.com/post-images/1616927489686.jpg" alt="" loading="lazy"><br>
而<code>DDD</code>更是在面向对象的方法下面，更加高度的提出了一种对整个项目更加有益的设计思想。</p>
<h3 id="什么是领域驱动设计">什么是领域驱动设计</h3>
<p>领域驱动设计（Domain Driven Design)，在面对对象的基础上提出了一种更加有效的设计思想，让我们在开发以及项目管理上，能得到更好的优势。<br>
在一个对开发人员完全陌生的一个领域时，我们需要让开发人员理解这个领域的知识才能更开发出实用的软件系统。不然就是一些不懂领域的人开发出不符合实际的情况的东西，这将造成时间和成本上的浪费。</p>
<ul>
<li>bounted context 限界上下文</li>
<li>core domain 核心领域 common domain 通用领域</li>
<li>domain event 领域事件</li>
<li>domain service 领域服务</li>
<li>聚合根 aggregate root</li>
<li>value object 值对象 entity 实体</li>
<li>infrastructure 基础</li>
<li>module 模块</li>
<li>factory 工厂</li>
<li></li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[Docker 网络]]></title>
        <id>https://blog.zhuxingzhao.com/post/docker-wang-luo/</id>
        <link href="https://blog.zhuxingzhao.com/post/docker-wang-luo/">
        </link>
        <updated>2019-04-13T15:59:51.000Z</updated>
        <content type="html"><![CDATA[<h4 id="docker网络概述">Docker网络概述</h4>
<p>Docker 作为当下主流容器技术，其网络通信是其中比较重要的一环，Docker实际使用中会遇到如下的情况</p>
<ul>
<li>
<p>单机Docker网络通信</p>
<figure data-type="image" tabindex="1"><img src="https://blog.zhuxingzhao.com/post-images/1623600224477.png" alt="" loading="lazy"></figure>
</li>
<li>
<p>多机Docker网络通信<br>
<img src="https://blog.zhuxingzhao.com/post-images/1623600256205.png" alt="" loading="lazy"></p>
</li>
</ul>
<p>在单机的情况下，Docker提供了5种网络模式供我们选择</p>
<ol>
<li>bridge网络模式</li>
<li>host网络模式</li>
<li>other-container网络模式</li>
<li>none网络模式</li>
<li>自定义模式</li>
</ol>
<blockquote>
<p>docker源码 <code>github.com/docker/docker/api/types/container/hostconfig_unix.go</code></p>
</blockquote>
<p>在源码里我们可以看到几种模式的定义</p>
<pre><code class="language-go">// NetworkName 返回网络栈的名称
func (n NetworkMode) NetworkName() string {
   if n.IsBridge() {
      return &quot;bridge&quot;
   } else if n.IsHost() {
      return &quot;host&quot;
   } else if n.IsContainer() {
      return &quot;container&quot;
   } else if n.IsNone() {
      return &quot;none&quot;
   } else if n.IsDefault() {
      return &quot;default&quot;
   } else if n.IsUserDefined() {
      return n.UserDefined()
   }
   return &quot;&quot;
}
</code></pre>
<p>在多机的情况下Docker的网络互通有以下方式</p>
<ul>
<li>docker网桥实现跨主机连接</li>
<li>Open vSwitch实现跨主机容器连接</li>
<li>使用weave实现跨主机容器连接</li>
<li>等等（还有许多方式的网络互通）</li>
</ul>
<h3 id="docker单机网络">Docker单机网络</h3>
<blockquote>
<p>在开始下面的内容之前，我们先梳理一下docker cli 从执行<code>docker run ….</code>命令到<code>docker daemon</code>的过程中，发生了什么。</p>
<p><code>Dokcer cli</code> 与 <code>Docker daemon</code> 的交互其实是典型的cs模式，而且其中的交互是使用请求（socket, http）的方式进行的，<code>Docker daemon</code>通过开启一个服务器来监听请求，例如<code>docker run ...</code>会发生以下的请求</p>
<p>![未命名表单 (https://blog.zhuxingzhao.com/post-images/1623600316756.png)</p>
<p><code>Dcoker Server</code>是以restful-api的形式管理的,可以看到对container的操作api就可以知道</p>
<pre><code class="language-go">	// HEAD
	router.NewHeadRoute(&quot;/containers/{name:.*}/archive&quot;, r.headContainersArchive),
	// GET
	router.NewGetRoute(&quot;/containers/json&quot;, r.getContainersJSON),
	router.NewGetRoute(&quot;/containers/{name:.*}/export&quot;, r.getContainersExport),
	router.NewGetRoute(&quot;/containers/{name:.*}/changes&quot;, r.getContainersChanges),
	router.NewGetRoute(&quot;/containers/{name:.*}/json&quot;, r.getContainersByName),
	router.NewGetRoute(&quot;/containers/{name:.*}/top&quot;, r.getContainersTop),
	router.NewGetRoute(&quot;/containers/{name:.*}/logs&quot;, r.getContainersLogs),
	router.NewGetRoute(&quot;/containers/{name:.*}/stats&quot;, r.getContainersStats),
	router.NewGetRoute(&quot;/containers/{name:.*}/attach/ws&quot;, r.wsContainersAttach),
	router.NewGetRoute(&quot;/exec/{id:.*}/json&quot;, r.getExecByID),
	router.NewGetRoute(&quot;/containers/{name:.*}/archive&quot;, r.getContainersArchive),
	// POST
	router.NewPostRoute(&quot;/containers/create&quot;, r.postContainersCreate),
	router.NewPostRoute(&quot;/containers/{name:.*}/kill&quot;, r.postContainersKill),
	router.NewPostRoute(&quot;/containers/{name:.*}/pause&quot;, r.postContainersPause),
	router.NewPostRoute(&quot;/containers/{name:.*}/unpause&quot;, r.postContainersUnpause),
	router.NewPostRoute(&quot;/containers/{name:.*}/restart&quot;, r.postContainersRestart),
	router.NewPostRoute(&quot;/containers/{name:.*}/start&quot;, r.postContainersStart),
	router.NewPostRoute(&quot;/containers/{name:.*}/stop&quot;, r.postContainersStop),
	router.NewPostRoute(&quot;/containers/{name:.*}/wait&quot;, r.postContainersWait),
	router.NewPostRoute(&quot;/containers/{name:.*}/resize&quot;, r.postContainersResize),
	router.NewPostRoute(&quot;/containers/{name:.*}/attach&quot;, r.postContainersAttach),
	router.NewPostRoute(&quot;/containers/{name:.*}/copy&quot;, r.postContainersCopy), // Deprecated since 1.8, Errors out since 1.12
	router.NewPostRoute(&quot;/containers/{name:.*}/exec&quot;, r.postContainerExecCreate),
	router.NewPostRoute(&quot;/exec/{name:.*}/start&quot;, r.postContainerExecStart),
	router.NewPostRoute(&quot;/exec/{name:.*}/resize&quot;, r.postContainerExecResize),
	router.NewPostRoute(&quot;/containers/{name:.*}/rename&quot;, r.postContainerRename),
	router.NewPostRoute(&quot;/containers/{name:.*}/update&quot;, r.postContainerUpdate),
	router.NewPostRoute(&quot;/containers/prune&quot;, r.postContainersPrune),
	router.NewPostRoute(&quot;/commit&quot;, r.postCommit),
	// PUT
	router.NewPutRoute(&quot;/containers/{name:.*}/archive&quot;, r.putContainersArchive),
	// DELETE
	router.NewDeleteRoute(&quot;/containers/{name:.*}&quot;, r.deleteContainers)
</code></pre>
<p>以<code>docker run</code>举例<br>
<code>docker cli</code>会进行run 后面的解析</p>
<blockquote>
<p>github.com/docker-ce/components/cli/cli/command/container/opts.go</p>
<p>会有每一个跟container通用选项的源码设置</p>
</blockquote>
<p><code>run</code>命令一些自己的参数设在</p>
<blockquote>
<p>github.com/docker-ce/components/cli/cli/command/container/run.go</p>
</blockquote>
<p>我们可以在源码中看到如下的代码，说明<code>run</code>会首先创建一个<code>container</code></p>
<pre><code class="language-go">createResponse, err := createContainer(ctx, dockerCli, containerConfig, &amp;opts.createOptions)
</code></pre>
<p>然后该函数会会在其中检查opts参数的pull属性判断需不需要拉取<code>images</code>，如果需要就会先执行<code>createContainer</code>定义的一个pullAndTagImages的函数，取发送一个请求拉取一个<code>image</code><br>
随后就会执行真正的<code>dockerCli.Client().ContainerCreate</code>方法将参数传递到<code>Docker Daemon</code>中开始创建一个<code>container</code></p>
<pre><code class="language-go">serverResp, err := cli.post(ctx, &quot;/containers/create&quot;, query, body, nil)
</code></pre>
<p>可以看到<code>dockerCli.Client().ContainerCreate</code>发送了一个<code>post</code>请求到了<code>Docker Daemon</code><br>
然后将我们的目光放到<code>Docker Daemon</code>开启的<code>server</code>中</p>
<blockquote>
<p>github.com/docker-ce/components/engine/api/server/router/container/container.go<br>
从中我们可以看到<code>/containers/create</code>路由的注册</p>
</blockquote>
<pre><code class="language-go">router.NewPostRoute(&quot;/containers/create&quot;, r.postContainersCreate),
</code></pre>
<p>注册的handler函数会执行其中的</p>
<pre><code class="language-go">ccr, err := s.backend.ContainerCreate(types.ContainerCreateConfig{
	Name:             name,
	Config:           config,
	HostConfig:       hostConfig,
	NetworkingConfig: networkingConfig,
	AdjustCPUShares:  adjustCPUShares,
}) 
</code></pre>
<p>将调用实际<code>Docker daemon</code>方法来进行容器的创建</p>
<pre><code class="language-go">func (daemon *Daemon) ContainerCreate(params types.ContainerCreateConfig) (containertypes.ContainerCreateCreatedBody, error) {
return daemon.containerCreate(createOpts{
	params:                  params,
	managed:                 false,
	ignoreImagesArgsEscaped: false})
}
</code></pre>
<p>最终通过一系列的设置网络，layer等最终创建了一个容器并返回给了<code>docker cli</code></p>
<p>随后<code>docker cli</code>会发起<code>start container</code>请求</p>
<pre><code class="language-go">router.NewPostRoute(&quot;/containers/{name:.*}/start&quot;, r.postContainersStart),
</code></pre>
<p>这个handler会进行参数校验后执行</p>
<pre><code class="language-go">s.backend.ContainerStart(vars[&quot;name&quot;], hostConfig, checkpoint, checkpointDir)
</code></pre>
<p>然后最终调用到<code>daemon</code>的<code>containerStart</code>方法去启动一个容器而我们的网络初始化也在这里</p>
</blockquote>
<p>从上文中我们了解到，<code>docker run</code>一个容器的过程中，会发送两个请求到<code>daemon</code>中，第一次创建一个容器，实际上是对一个容器的内存抽象，这里会将各种参数配置进去，当然包括我们的网络配置，第二次请求实际创建了容器，网络的实际的初始化在这个阶段进行。</p>
<h4 id="bridge网络模式">Bridge网络模式</h4>
<blockquote>
<p>在源码中bridge模式，会在<code>create container</code>的过程中配置到抽象的容器实例中，然后在start container的过程中，通过</p>
<pre><code class="language-go">daemon.allocateNetwork(container)
</code></pre>
<p>来分配网络接口设备信息</p>
<p>其中会调用</p>
<pre><code class="language-go">daemon.connectToNetwork(container, defaultNetName, nConf.EndpointSettings, updateSetting)
</code></pre>
<p>该函数会创建相应的<code>sandbox</code>、<code>endpoint</code>然后将<code>endpoint</code>跟<code>sandbox</code>绑定</p>
<blockquote>
<p><strong>Sandbox</strong></p>
</blockquote>
<blockquote>
<p>一个Sandbox包含了一个容器网络栈的配置。其中包括了对容器的网卡，路由表以及对DNS设置的管理。通常，一个Sandbox的实现可以是一个Linux Network Namespace，一个FreeBSD Jail或者其他类似的东西。一个Sandbox可以包含多个处于不同Network的Endpoint。</p>
</blockquote>
<blockquote>
<p><strong>Endpoint</strong></p>
</blockquote>
<blockquote>
<p>Endpoint将一个Sandbox加入一个Network。Endpoint的实现可以是一个veth对，一个Open vSwitch internal port或者其他类似的东西。一个Endpoint只能属于一个Network和一个Sandbox。</p>
</blockquote>
<blockquote>
<p><strong>Network</strong></p>
</blockquote>
<blockquote>
<p>Network是一个能够互相通信的Endpoint的集合。Network的实现可以是一个Linux网桥，一个VLAN等等。</p>
</blockquote>
</blockquote>
<p><code>bridge</code>网络是<code>docker</code>默认的网络模式，该模式为<code>Docker Container</code>创建了一个独立的网络空间，保证容器内的进程组使用独立的网络环境，实现了容期间，容器和主机之间的网络空间隔离。还可以通过host上的网桥(<code>docker0</code>)来连通容器内部的网络空间和host的网络空间，实现容器和host的网络通信，甚至和外网的通信。</p>
<p>Bridge主要通过以下方式实现</p>
<ol>
<li>Docker Daemon 在创建容器时，会在<code>host</code>上创建两个虚拟网络接口设备，例如<code>veth1</code>和<code>veth2</code>，保证一个接受<br>
到的网络报文都能传给另外一方</li>
<li>Docker Daemon 将<code>veth1</code>加到<code>docker1</code>的网桥上，从而转发<code>host</code>的网络报文</li>
<li>将<code>veth1</code>挂到<code>container</code>的网络空间下面，并改为<code>eth0</code>，这样一来就实现了<code>container</code>的网络隔离以及跟<code>host</code>及外网的网络通信</li>
</ol>
<p>如此虽然已经实现了container的网络隔离和网络连通性，但依然无法使外界请求到达<code>container</code>如此我还需要使用NAT的方式，将网络报文发往<code>container</code></p>
<p>所以当<code>container</code>需要暴露服务时，内部的服务是需要监听容器<code>ip</code>和<code>port</code>的，这样才能使用NAT的方式转发到对应的内部服务。在<code>linux</code>上主要使用<code>iptables</code>来进行网络转发（当然需要	<code>linux</code>支持<code>ipv4</code>网络报文转发的能力, 在Docker Daemon启动时，会检查<code>linux</code>是否支持<code>ipv4</code>转发，不能<code>ipv4</code>转发是无法启动Docker Daemon的）</p>
<p>具体<code>iptables</code>如下</p>
<pre><code class="language-bash">iptables -I FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
</code></pre>
<p>该模式的有点很明显，隔离了<code>container</code>的网络空间，但时缺点也很明显，在暴露内部服务时，依然依赖于<code>host</code>的端口和公网ip，没有自己独立的<code>ip</code>和<code>port</code>，而且中间经过了转发，是有一定的传输效率的</p>
<h4 id="host网络模式">host网络模式</h4>
<blockquote>
<p>从上文中我们知道，网络初始化在start container的过程中</p>
<p>在<code>initializeNetworking</code>方法中我们可以看到如果是<code>host</code>模式就与<code>host</code>共享网络资源</p>
<pre><code class="language-go">if container.HostConfig.NetworkMode.IsHost() {
   if container.Config.Hostname == &quot;&quot; {
      container.Config.Hostname, err = os.Hostname()
      if err != nil {
         return err
      }
   }
}
</code></pre>
</blockquote>
<p>该模式就如同名字一样，就是共享<code>host</code>的网络空间，并没有为<code>container</code>创建独立的隔离网络环境，所以该模式的<code>container</code>和<code>host</code>一起使用<code>eth0</code>, 即<code>docker</code>的<code>ip</code>和端口，就是<code>host</code>的<code>ip</code>和端口</p>
<figure data-type="image" tabindex="2"><img src="http://blog.daocloud.io/wp-content/uploads/2015/01/Docker_Network_host.jpg" alt="17" loading="lazy"></figure>
<p>在模式下，我们明显脱离了一层nat转发的过程，保证了网络传输的可靠性和传输速度。在对网络环境不要求的一些服务同时又要求网络性能的情况下，该种模式是很有必要的，与bridge模式形成了很好的不出</p>
<h4 id="other-container网络模式">other-container网络模式</h4>
<blockquote>
<p>接上文在<code>initializeNetworking</code>方法中可以看到如果是<code>container</code>就会将该其他容器的网络空间与该容器绑定，从而共享网络空间</p>
<pre><code class="language-go">if container.HostConfig.NetworkMode.IsContainer() {
   // we need to get the hosts files from the container to join
   nc, err := daemon.getNetworkedContainer(container.ID, container.HostConfig.NetworkMode.ConnectedContainer())
   if err != nil {
      return err
   }

   err = daemon.initializeNetworkingPaths(container, nc)
   if err != nil {
      return err
   }

   container.Config.Hostname = nc.Config.Hostname
   container.Config.Domainname = nc.Config.Domainname
   return nil
}
</code></pre>
</blockquote>
<p>这个模式是<code>docker</code>一个特殊的网络模式，在这个模式下的<code>container</code>会借助其他容器的网络环境，之所以称为“特别”，是因为这个模式下容器的网络隔离性会处于<code>bridge</code>桥接模式与<code>host</code>模式之间。<code>Docker Container</code>共享其他容器的网络环境，则至少这两个容器之间不存在网络隔离，而这两个容器又与宿主机以及除此之外其他的容器存在网络隔离。</p>
<figure data-type="image" tabindex="3"><img src="http://blog.daocloud.io/wp-content/uploads/2015/01/Docker_network_other_container.jpg" alt="17" loading="lazy"></figure>
<p>实现该模式只需要将<code>namespace</code>使用<code>other container</code>的<code>namespace</code>即可</p>
<p>在这种模式下的<code>Docker Container</code>可以通过<code>localhost</code>来访问<code>namespace</code>下的其他容器，传输效率较高。虽然多个容器共享网络环境，但是多个容器形成的整体依然与宿主机以及其他容器形成网络隔离。另外，这种模式还节约了一定数量的网络资源。但是需要注意的是，它并没有改善容器与宿主机以外世界通信的情况。</p>
<h4 id="none模式">none模式</h4>
<p>该模式顾名思义，即不设置任何的网络模式，一旦设置改模式，容器内只有lp回环网络，不会再有其他的网络资源。所以相当隔壁，相当的纯粹。</p>
<h4 id="自定义模式">自定义模式</h4>
<p>上文提到<code>docker</code>有<code>none</code>的模式，在此模式，<code>docker</code>对<code>container</code>的网络基本不做任何设置，所以我们可以自定义网络，从而实现我们所面对的业务场景。这也恰巧体现了<code>Docker</code>设计理念的开放。</p>
<h5 id="容器间通信">容器间通信</h5>
<p>通过以上我们了解到了<code>docker</code>的网络模式，我们面对了一个实际场景就是容器之间的通信，因为我们的服务可能是多服务的组成共同对外服务，例如传统的<code>lnmp</code>服务我们需要<code>php</code>、<code>mysql</code>、<code>nginx</code>甚至我们还需要<code>redis</code>的三方服务。这些服务各自为一个容器，我们需要他们互相通信，组成一个服务对外提供。</p>
<p>这里我们主要使用<code>Docker Bridge</code>模式，从前文我们知道在<code>bridge</code>的模式下，我们的<code>container</code>的网络设备与<code>docker0</code>连通，所以我们的<code>eth0</code>会被分配在<code>docker0</code>下面的网络子网，一般为<code>172.17.x.1</code>这个网段下面。</p>
<p>所以我们可以通过以下三种方式</p>
<ol>
<li>
<p>容器的ip通信</p>
<p>我们可以通过<code>docker inspect</code>查询到<code>container</code>到内部ip进行通信，但是这样会导致硬编码，而且从新开启一个<code>container</code>之后ip又变了，也不方便迁移</p>
</li>
<li>
<p>host的端口映射</p>
<p>通过绑定<code>host</code>的<code>ip</code>的<code>port</code>的进行通信，但是依赖于外部端口进行有限的通信，做不到灵活性</p>
</li>
<li>
<p>通过容器名</p>
<p>可以使用容器名，通过<code>docker</code>的<code>link</code>机制通信。这种方式通过<code>docker</code>的<code>link</code>机制可以通过一个name来和另一个容器通信，link机制方便了容器去发现其它的容器并且可以安全的传递一些连接信息给其它的容器。使用name给容器起一个别名，方便记忆和使用。即使容器重启了，地址发生了变化，不会影响两个容器之间的连接</p>
</li>
</ol>
<p>我们主要使用第三种方式进行主机内同学，我们可以使用<code>docker-composer</code>通过<code>docker-compose.yaml</code>定义一个服务，<code>docker-composer</code>能根据配置文件帮我创建一个多容器服务互相通信的应用服务</p>
<p>以下是一个<code>laravel</code>、<code>php</code>、<code>nginx</code>、<code>mysql</code>、<code>redis</code>组成的一个服务通过d<code>ocker-compose.yaml</code>编排</p>
<pre><code>version: '2'

services:
  nginx:
    depends_on:
      - &quot;php&quot;
    image: &quot;nginx&quot;
    restart: unless-stopped
    volumes:
      - &quot;$PWD/deploy/nginx:/etc/nginx/conf.d&quot;
      - &quot;$PWD:/var/www/html&quot;
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    ports:
      - &quot;80:80&quot;
      - &quot;443:443&quot;
    networks:
      - app-network
    command: &quot;/bin/sh -c 'while :; do sleep 6h &amp; wait $${!}; nginx -s reload; done &amp; nginx -g \&quot;daemon off;\&quot;'&quot;
  certbot:
    image: certbot/certbot
    restart: unless-stopped
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    entrypoint: &quot;/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h &amp; wait $${!}; done;'&quot;

  php:
    image: &quot;php&quot;
    restart: unless-stopped
    volumes:
      - &quot;$PWD:/var/www/html&quot;
    build:
      context: .
      dockerfile: &quot;Dockerfile&quot;
    working_dir: /var/www/html
#    entrypoint:
#      - ls /var/www/html
#      - chmod +x /var/www/html/deploy/run
#      - /var/www/html/deploy/run
    networks:
      - app-network


  mysql:
    image: mysql:5.7
    volumes:
      - &quot;$PWD/data/mysql:/var/lib/mysql&quot;
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: xxxx
      MYSQL_DATABASE: xxx
      MYSQL_USER: xxxx
      MYSQL_PASSWORD: xxx
    ports:
      - &quot;3306:3306&quot;
    networks:
      - app-network


  redis:
    image: &quot;redis&quot;
    restart: unless-stopped
    ports:
      - &quot;6379:6379&quot;
    networks:
      - app-network
#    volumes:

networks:
  app-network:
    driver: bridge
</code></pre>
<p>从而用<code>docker-compose up</code>即可开启一套容器服务</p>
<blockquote>
<p>参考资料</p>
</blockquote>
<blockquote>
<p>docker 源码解析</p>
</blockquote>
]]></content>
    </entry>
</feed>