关于技术栈:从零开始搭建创业公司后台技术栈

小 Hub 领读：

好长的一篇文章，说到守业，很多人都有激情，你晓得在守业公司当架构师是个什么样的体验吗，你先来看看搭建企业技术栈须要什么技术栈，你思考好了没？

作者 | 潘锦

出处 | 架构与远方

博客 | phppan.com/2018/04/svr-stack

前言

说到后盾技术栈，脑海中是不是浮现的是这样一幅图？

有点眼晕，以下只是咱们会用到的一些语言的合集，而且只是语言层面的一部分，就整个后盾技术栈来说，这只是一个开始，从语言开始，还有很多很多的内容。明天要说的后盾是大后盾的概念，放在服务器上的货色都属于后盾的货色，比方应用的框架，语言，数据库，服务，操作系统等等。

整个后盾技术栈我的了解包含 4 个层面的内容：

• 语言：用了哪些开发语言，如：C++/Java/Go/PHP/Python/Ruby 等等；
• 组件：用了哪些组件，如：MQ 组件，数据库组件等等；
• 流程：怎么的流程和标准，如：开发流程，我的项目流程，公布流程，监控告警流程，代码标准等等；
• 零碎：系统化建设，下面的流程须要有零碎来保障，如：标准公布流程的公布零碎，代码管理系统等等；

联合以上的的 4 个层面的内容，整个后盾技术栈的构造如图 2 所示：

图 2 后盾技术栈构造

以上的这些内容都须要咱们从零开始搭建，在守业公司，没有大公司那些欠缺的基础设施，须要咱们从开源界，从云服务商甚至有些须要本人去组合，去拼装，去开发一个适宜本人的组件或零碎以达成咱们的指标。咱们一个个零碎和组件的做选型，最终造成咱们的后盾技术栈。

各零碎组件选型

1、项目管理 / Bug 治理 / 问题治理

项目管理软件是整个业务的需要，问题，流程等等的集中地，大家的跨部门沟通协同大多依赖于项目管理工具。有一些 SaaS 的项目管理服务能够应用，然而很多工夫不满足需要，此时咱们能够抉择一些开源的我的项目，这些我的项目自身有肯定的定制能力，有丰盛的插件能够应用，个别的守业公司需要基本上都能失去满足，罕用的我的项目如下：

• Redmine：用 Ruby 开发的，有较多的插件能够应用，能自定义字段，集成了项目管理，Bug 问题跟踪，WIKI 等性能，不过好多插件 N 年没有更新了；
• Phabricator：用 PHP 开发的，Facebook 之前的外部工具，开发这工具的哥们到职后本人搞了一个公司专门做这个软件，集成了代码托管，Code Review，工作治理，文档治理，问题跟踪等性能，强烈推荐较麻利的团队应用；
• Jira：用 Java 开发的，有用户故事，task 拆分，燃尽图等等，能够做项目管理，也能够利用于跨部门沟通场景，较弱小；
• 悟空 CRM：这个不是项目管理，这个是客户治理，之所以在这里提出来，是因为在 To B 的守业公司外面，往往是以客户为外围来做事件的，能够将项目管理和问题跟进的在悟空 CRM 下面来做，他的开源版本曾经根本实现了 CR< 的外围 性能，还带有一个工作治理性能，用于问题跟进，不过用这个的话，还是须要另一个项目管理的软件帮助，顺便说一嘴，这个零碎的代码写得很难保护，只能实用于客户规模小（1 万以内）时。

2、DNS

DNS 是一个很通用的服务，守业公司基本上抉择一个适合的云厂商就行了，国内次要是两家：

• 阿里万网：阿里 2014 年收买了万网，整合了其域名服务，最终造成了当初的阿里万网，其中就蕴含 DNS 这块的服务；
• 腾讯 DNSPod：腾讯 2012 年以 4000 万收买 DNSPod 100% 股份，次要提供域名解析和一些防护性能；

如果你的业务是在国内，次要就是这两家，选 一个就好，像今日头条这样的企业用的也是 DNSPod 的服务，除非一些非凡的起因才须要自建，比方一些 CDN 厂商，或者对区域有非凡限度的。要实惠一点用阿里最便宜的根底版就好了，要成功率高一些，还是用 DNSPod 的贵的那种。

在国外还是抉择亚马逊吧，阿里的 DNS 服务只有在日本和美国有节点，东南亚最近才开始部点，DNSPod 也只有美国和日本，像一些出海的企业，其抉择的云服务根本都是亚马逊。

如果是线上产品，DNS 强烈建议用付费版，阿里的那几十块钱的付费版根本能够满足需要。如果还须要一些按省份或按区域调试的逻辑，则须要加钱，一年也就几百块，省钱省力。

如果是国外，优先选择亚马逊，如果须要国内外互通并且有本人的 APP 的话，倡议还是本人实现一些容灾逻辑或者智能调度，因为没有一个现成的 DNS 服务能同时较好的满足国内外场景，或者用多个域名，不同的域名走不同的 DNS。

3、LB（负载平衡）

LB（负载平衡）是一个通用服务，个别云厂商的 LB 服务根本都会如下性能：

• 反对四层协定申请（包含 TCP、UDP 协定）；
• 反对七层协定申请（包含 HTTP、HTTPS 协定）；
• 集中化的证书管理系统反对 HTTPS 协定；
• 健康检查；

如果你线上的服务机器都是用的云服务，并且是在同一个云服务商的话，能够间接应用云服务商提供的 LB 服务，如阿里云的 SLB，腾讯云的 CLB，亚马逊的 ELB 等等。如果是自建机房根本都是 LVS + Nginx。

4、CDN

CDN 当初曾经是一个很红很红的市场，基本上只能挣一些辛苦钱，都是贴着老本在卖。国内以网宿为龙头，他们家占据整个国内市场份额的 40% 以上，前面就是腾讯，阿里。网宿有很大一部分是因为直播的衰亡而崛起。

国外，Amazon 和 Akamai 合起来占比大略在 50%，已经的国内市场老大 Akamai 领有寰球超一半的份额，在 Amazon CDN 入局后，份额跌去了将近 20%，泛滥中小企业都转向后者，Akamai 也是无能为力。

国内出海的 CDN 厂商，更多的是为国内的出海企业服务，三家大一点的 CDN 服务商外面也就网宿的节点多一些，然而也多不了多少。阿里和腾讯还处于后期阶段，仅少部分国家有节点。

就守业公司来说，CDN 用腾讯云或阿里云即可，其相干零碎较欠缺，能轻松接入，网宿在零碎反对层面绝对较弱一些，而且还贵一些。并且，当流量上来后，CDN 不能只用一家，须要用多家，不同的 CDN 在全国的节点笼罩不一样，而且针对不同的客户云厂商外部有些辨别客户集群，并不是全节点笼罩（但有些云厂商说本人是全网节点），除了节点笼罩的问题，多 CDN 也在肯定水平上起到容灾的作用。

5、RPC 框架

维基百科对 RPC 的定义是：近程过程调用（Remote Procedure Call，RPC）是一个计算机通信协议。该协定容许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额定地为这个交互作用编程。

艰深来讲，一个残缺的 RPC 调用过程，就是 Server 端实现了一个函数，客户端应用 RPC 框架提供的接口，调用这个函数的实现，并获取返回值的过程。

业界 RPC 框架大抵分为两大流派，一种偏重跨语言调用，另一种是并重服务治理。

跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用，可能反对大部分的语言进行语言无关的调用，非常适合多语言调用场景。但这类框架没有服务发现相干机制，理论应用时须要代理层进行申请转发和负载平衡策略管制。

其中，gRPC 是 Google 开发的高性能、通用的开源 RPC 框架，其由 Google 次要面向挪动利用开发并基于 HTTP/2 协定规范而设计，基于 ProtoBuf（Protocol Buffers）序列化协定开发，且反对泛滥开发语言。自身它不是分布式的，所以要实现框架的性能须要进一步的开发。

Hprose（High Performance Remote Object Service Engine）是一个 MIT 开源许可的新型轻量级跨语言跨平台的面向对象的高性能近程动静通信中间件。

服务治理型的 RPC 框架的特点是功能丰富，提供高性能的近程调用、服务发现及服务治理能力，实用于大型服务的服务解耦及服务治理，对于特定语言 (Java) 的我的项目能够实现透明化接入。毛病是语言耦合度较高，跨语言反对难度较大。国内常见的冶理型 RPC 框架如下：

• Dubbo：Dubbo 是阿里巴巴公司开源的一个 Java 高性能优良的服务框架，使得利用可通过高性能的 RPC 实现服务的输入和输出性能，能够和 Spring 框架无缝集成。当年在淘宝外部，Dubbo 因为跟淘宝另一个相似的框架 HSF 有竞争关系，导致 Dubbo 团队遣散，最近又活过来了，有专职同学投入。
• DubboX：DubboX 是由当当在基于 Dubbo 框架扩大的一个 RPC 框架，反对 REST 格调的近程调用、Kryo/FST 序列化，减少了一些新的 feature。Motan：Motan 是新浪微博开源的一个 Java 框架。它诞生的比拟晚，起于 2013 年，2016 年 5 月开源。Motan 在微博平台中曾经广泛应用，每天为数百个服务实现近千亿次的调用。
• rpcx：rpcx 是一个相似阿里巴巴 Dubbo 和微博 Motan 的分布式的 RPC 服务框架，基于 Golang net/rpc 实现。然而 rpcx 根本只有一个人在保护，没有欠缺的社区，应用前要谨慎，之前做 Golang 的 RPC 选型时也有思考这个，最终还是放弃了，抉择了 gRPC，如果想本人自研一个 RPC 框架，能够参考学习一下。

6、名字发现 / 服务发现

名字发现和服务发现分为两种模式，一个是客户端发现模式，一种是服务端发现模式。

框架中罕用的服务发现是客户端发现模式。

所谓服务端发现模式是指客户端通过一个负载均衡器向服务发送申请，负载均衡器查问服务注册表并把申请路由到一台可用的服务实例上。当初罕用的负载均衡器都是此类模式，罕用于微服务中。

所有的名字发现和服务发现都要依赖于一个可用性十分高的服务注册表，业界罕用的服务注册表有如下三个：

• etcd，一个高可用、分布式、一致性、key-value 形式的存储，被用在分享配置和服务发现中。两个驰名的我的项目应用了它：Kubernetes 和 Cloud Foundry。
• Consul，一个发现和配置服务的工具，为客户端注册和发现服务提供了 API，Consul 还能够通过执行健康检查决定服务的可用性。
• Apache ZooKeeper，是一个宽泛应用、高性能的针对分布式应用的协调服务。Apache ZooKeeper 原本是 Hadoop 的子工程，当初曾经是顶级工程了。

除此之外也能够本人实现服务实现，或者用 Redis 也行，只是须要本人实现高可用性。

7、关系数据库

关系数据库分为两种，一种是传统关系数据，如 Oracle，MySQL，Maria，DB2，PostgreSQL 等等，另一种是 NewSQL，即至多要满足以下五点的新型关系数据库：

1. 残缺地反对 SQL，反对 JOIN / GROUP BY / 子查问等简单 SQL 查问。
2. 反对传统数据标配的 ACID 事务，反对强隔离级别。
3. 具备弹性伸缩的能力，扩容缩容对于业务层齐全通明。
4. 真正的高可用，异地多活、故障复原的过程不须要人为的接入，零碎可能主动地容灾和进行强统一的数据恢复。
5. 具备肯定的大数据分析能力。

传统关系数据库用得最多的是 MySQL，成熟，稳固，一些根本的需要都能满足，在肯定数据量级之前根本单机传统数据库都能够搞定，而且当初较多的开源零碎都是基于 MySQL，开箱即用，再加上主从同步和前端缓存，百万 pv 的利用都能够搞定了。不过 CentOS 7 曾经放弃了 MySQL，而改应用 MariaDB。MariaDB 数据库管理系统是 MySQ L 的一个分支，次要由开源社区在保护，采纳 GPL 受权许可。开发这个分支的起因之一是：甲骨文公司收买了 MySQL 后，有将 MySQL 闭源的潜在危险，因而社区采纳分支的形式来避开这个危险。

在 Google 公布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 之后，业界开始风行起 NewSQL。于是有了 CockroachDB，于是有了奇叔公司的 TiDB。国内曾经有比拟多的公司应用 TiDB，之前在守业公司时在大数据分析时曾经开始利用 TiDB，过后利用的次要起因是 MySQL 要应用分库分表，逻辑开发比较复杂，扩展性不够。

8、NoSQL

NoSQL 顾名思义就是 Not-Only SQL，也有人说是 No – SQL，集体偏差于 Not-Only SQL，它并不是用来代替关系库，而是作为关系型数据库的补充而存在。

常见 NoSQL 有 4 个类型：

• 键值，实用于内容缓存，适宜混合工作负载并发高扩大要求大的数据集，其长处是简略，查问速度快，毛病是短少结构化数据，常见的有 Redis，Memcache，BerkeleyDB 和 Voldemort 等等；
• 列式，以列簇式存储，将同一列数据存在一起，常见于分布式的文件系统，其中以 Hbase，Cassandra 为代表。Cassandra 多用于写多读少的场景，国内用得比拟多的有 360，大略 1500 台机器的集群，国外大规模应用的公司比拟多，如 eBay，Instagram，Apple 和沃尔玛等等；
• 文档，数据存储计划十分实用承载大量不相干且构造差异很大的简单信息。性能介于 kv 和关系数据库之间，它的灵感来于 lotus notes，常见的有 MongoDB，CouchDB 等等；
• 图形，图形数据库善于解决任何波及关系的情况。社交网络，举荐零碎等。专一于构建关系图谱，须要对整个图做计算能力得出后果，不容易做分布式的集群计划，常见的有 Neo4J，InfoGrid 等。

除了以上 4 种类型，还有一些特种的数据库，如对象数据库，XML 数据库，这些都有针对性对某些存储类型做了优化的数据库。

在理论利用场景中，何时应用关系数据库，何时应用 NoSQL，应用哪种类型的数据库，这是咱们在做架构选型时一个十分重要的考量，甚至会影响整个架构的计划。

9、消息中间件

消息中间件在后盾零碎中是必不可少的一个组件，个别咱们会在以下场景中应用消息中间件：

• 异步解决：异步解决是应用消息中间件的一个次要起因，在工作中最常见的异步场景有用户注册胜利后须要发送注册胜利邮件、缓存过期时先返回老的数据，而后异步更新缓存、异步写日志等等；通过异步解决，能够缩小主流程的期待响应工夫，让非主流程或者非重要业务通过消息中间件做集中的异步解决。
• 零碎解耦：比方在电商零碎中，当用户胜利领取实现订单后，须要将领取后果给告诉 ERP 零碎、发票零碎、WMS、举荐零碎、搜寻零碎、风控系统等进行业务解决；这些业务解决不须要实时处理、不须要强统一，只须要最终一致性即可，因而能够通过消息中间件进行零碎解耦。通过这种零碎解耦还能够应答将来不明确的零碎需要。
• 削峰填谷：当零碎遇到大流量时，监控图上会看到一个一个的山峰样的流量图，通过应用消息中间件将大流量的申请放入队列，通过消费者程序将队列中的解决申请缓缓消化，达到消峰填谷的成果。最典型的场景是秒杀零碎，在电商的秒杀零碎中下单服务往往会是零碎的瓶颈，因为下单须要对库存等做数据库操作，须要保障强一致性，此时应用消息中间件进行下单排队和流控，让下单服务缓缓把队列中的单解决完，爱护下单服务，以达到削峰填谷的作用。

业界消息中间件是一个十分通用的货色，大家在做选型时有应用开源的，也有本人造轮子的，甚至有间接用 MySQL 或 Redis 做队列的，要害看是否满足你的需要，如果是应用开源的我的项目，以下的表格在选型时能够参考：

图 3

以上图的纬度为：名字、成熟度、所属社区 / 公司、文档、受权形式、开发语言、反对的协定、客户端反对的语言、性能、长久化、事务、集群、负载平衡、治理界面、部署形式、评估。

10、代码治理

代码是互联网守业公司的命根子之一，代码治理很重要，常见的考量点包含两块：

• 平安和权限治理，将代码放到内网并且对于关系公司命根子的外围代码做严格的代码管制和机器的物理隔离；
• 代码管理工具，Git 作为代码治理的不二之选，你值得领有。GitLab 是当今最火的开源 Git 托管服务端，没有之一，尽管有企业版，然而其社区版根本能满足咱们大部分需要，联合 Gerrit 做 Code review，根本就完满了。当然 GitLab 也有代码比照，但没 Gerrit 直观。Gerrit 比 GitLab 提供了更好的代码查看界面与主线治理体验，更适宜在对代码品质有高要求的文化下应用。

11、继续集成

继续集成简，称 CI（continuous integration），是一种软件开发实际，即团队开发成员常常集成他们的工作，每天可能会产生屡次集成。每次集成都通过自动化的构建（包含编译，公布，自动化测试）来验证，从而尽早地发现集成谬误。继续集成为研发流程提供了代码分支治理 / 比对、编译、查看、公布物输入等根底工作，为测试的覆盖率版本编译、生成等提供对立反对。

业界收费的继续集成工具中零碎咱们有如下一些抉择：

• Jenkins：Java 写的有弱小的插件机制，MIT 协定开源（收费，定制化水平高，它能够在多台机器上进行分布式地构建和负载测试）。Jenkins 能够算是无所不能，根本没有 Jenkins 做不了的，无论从小型团队到大型团队 Jenkins 都能够搞定。不过如果要大规模应用，还是须要有人力来学习和保护。
• TeamCity：TeamCity 与 Jenkins 相比应用更加敌对，也是一个高度可定制化的平台。然而用的人多了，TeamCity 就要免费了。
• Strider：Strider 是一个开源的继续集成和部署平台，应用 Node.js 实现，存储应用的是 MongoDB，BSD 许可证，概念上相似 Travis 和 Jenkins。
• GitLab CI：从 GitLab 8.0 开始，GitLab CI 就曾经集成在 GitLab，咱们只有在我的项目中增加一个 .gitlab-ci.yml 文件，而后增加一个 Runner，即可进行继续集成。并且 GitLab 与 Docker 有着十分好的相互协作的能力。免费版与付费版本不同能够参见这里：https://about.gitlab.com/prod…。
• Travis：Travis 和 GitHub 强关联；闭源代码应用 SaaS 还需思考平安问题；不可定制；开源我的项目收费，其它免费。
• Go：Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身。除了 ThoughtWorks 提供的商业反对，Go 是收费的。它实用于 Windows，Mac 和各种 Linux 发行版。

12、日志零碎

日志零碎个别包含打日志，采集，直达，收集，存储，剖析，出现，搜寻还有散发等。一些非凡的如染色，全链条跟踪或者监控都可能须要依赖于日志零碎实现。日志零碎的建设不仅仅是工具的建设，还有标准和组件的建设，最好一些根本的日志在框架和组件层面加就行了，比方全链接跟踪之类的。

对于惯例日志零碎 ELK 能满足大部分的需要，ELK 包含如下组件：

• ElasticSearch 是个开源分布式搜索引擎，它的特点有：分布式，零配置，主动发现，索引主动分片，索引正本机制，RESTful 格调接口，多数据源，主动搜寻负载等。
• Logstash 是一个齐全开源的工具，它能够对你的日志进行收集、剖析，并将其存储供当前应用。
• Kibana 是一个开源和收费的工具，它能够为 Logstash 和 ElasticSearch 提供的日志剖析敌对的 Web 界面，能够帮忙汇总、剖析和搜寻重要数据日志。
• Filebeat 曾经齐全代替了 Logstash-Forwarder 成为新一代的日志采集器，同时鉴于它轻量、平安等特点，越来越多人开始应用它。

因为收费的 ELK 没有任何平安机制，所以这里应用了 Nginx 作反向代理，防止用户间接拜访 Kibana 服务器。加上配置 Nginx 实现简略的用户认证，肯定水平上进步安全性。另外，Nginx 自身具备负载平衡的作用，可能进步零碎拜访性能。ELK 架构如图 4 所示：

图 4，ELK 流程图

对于有实时计算的需要，能够应用 Flume + Kafka + Storm + MySQL 计划，一 般架构如图 5 所示：

图 5，实时剖析零碎架构图

其中：

• Flume 是一个分布式、牢靠、和高可用的海量日志采集、聚合和传输的日志收集零碎，反对在日志零碎中定制各类数据发送方，用于收集数据；同时，Flume 提供对数据进行简略解决，并写到各种数据接受方（可定制）的能力。
• Kafka 是由 Apache 软件基金会开发的一个开源流解决平台，由 Scala 和 Java 编写。其本质上是一个“依照分布式事务日志架构的大规模公布 / 订阅音讯队列”，它以可程度扩大和高吞吐率而被宽泛应用。

Kafka 谋求的是高吞吐量、高负载，Flume 谋求的是数据的多样性，二者联合起来几乎完满。

13、监控零碎

监控零碎只蕴含与后盾相干的，这里次要是两块，一个是操作系统层的监控，比方机器负载，IO，网络流量，CPU，内存等操作系统指标的监控。另一个是服务质量和业务品质的监控，比方服务的可用性，成功率，失败率，容量，QPS 等等。常见业务的监控零碎先有操作系统层面的监控（这部分较成熟），而后扩大出其它监控，如 Zabbix，小米的 Open-Falcon，也有一进去就是两者都反对的，如 Prometheus。如果对业务监控要求比拟高一些，在守业选型中倡议能够优先思考 Prometheus。这里有一个乏味的散布，如图 6 所示。

图 6，监控零碎散布

亚洲区域应用 Zabbix 较多，而美洲和欧洲，以及澳大利亚应用 Prometheus 居多，换句话说，英文国家地区（发达国家？）应用 Prometheus 较多。

Prometheus 是由 SoundCloud 开发的开源监控报警零碎和时序列数据库（TSDB）。Prometheus 应用 Go 语言开发，是 Google BorgMon 监控零碎的开源版本。绝对于其它监控零碎应用的 push 数据的形式，Prometheus 应用的是 pull 的形式，其架构如图 7 所示：

图 7，Prometheus 架构图

如上图所示，Prometheus 蕴含的次要组件如下：

• Prometheus Server 次要负责数据采集和存储，提供 PromQL 查询语言的反对。Server 通过配置文件、文本文件、ZooKeeper、Consul、DNS SRV Lookup 等形式指定抓取指标。依据这些指标会，Server 定时去抓取 metrics 数据，每个抓取指标须要裸露一个 http 服务的接口给它定时抓取。
• 客户端 SDK：官网提供的客户端类库有 Go、Java、Scala、Python、Ruby，其余还有很多第三方开发的类库，反对 Nodejs、PHP、Erlang 等。
• Push Gateway 反对临时性 Job 被动推送指标的两头网关。
• Exporter Exporter 是 Prometheus 的一类数据采集组件的总称。它负责从指标处收集数据，并将其转化为 Prometheus 反对的格局。与传统的数据采集组件不同的是，它并不向地方服务器发送数据，而是期待地方服务器被动前来抓取。Prometheus 提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前反对的有数据库、硬件、消息中间件、存储系统、HTTP 服务器、JMX 等。
• Alertmanager：是一个独自的服务，能够反对 Prometheus 的查问语句，提供非常灵便的报警形式。
• Prometheus HTTP API 的查问形式，自定义所须要的输入。
• Grafana 是一套开源的剖析监督平台，反对 Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch 等数据源，其 UI 十分丑陋且高度定制化。

守业公司抉择 Prometheus + Grafana 的计划，再加上对立的服务框架（如 gRPC），能够满足大部分中小团队的监控需要。

14、配置零碎

随着程序性能的日益简单，程序的配置日益增多：各种性能的开关、降级开关，灰度开关，参数的配置、服务器的地址、数据库配置等等，除此之外，对后台程序配置的要求也越来越高：配置批改后实时失效，灰度公布，分环境、分用户，分集群治理配置，欠缺的权限、审核机制等等，在这样的大环境下，传统的通过配置文件、数据库等形式曾经越来越无奈满足开发人员对配置管理的需要，业界有如下两种计划：

• 基于 zk 和 etcd，反对界面和 api，用数据库来保留版本历史，预案，走审核流程，最初下发到 zk 或 etcd 这种有推送能力的存储里（服务注册自身也是用 zk 或 etcd，选型就一块了）。客户端都间接和 zk 或 etcd 打交道。至于灰度公布，各家不同，有一种实现是同时公布一个须要灰度的 IP 列表，客户端监听到配置节点变动时，比照一下本人是否属于该列表。PHP 这种无状态的语言和其余 zk/etcd 不反对的语言，只好本人在客户端的机器上起一个 Agent 来监听变动，再写到配置文件或共享内存，如 360 的 Qconf。
• 基于运维自动化的配置文件的推送，审核流程，配置数据管理和计划一相似，下发时生成配置文件，基于运维自动化工具如 Puppet，Ansible 推送到每个客户端，而利用则定时从新读取这个内部的配置文件，灰度公布在下发配置时指定 IP 列表。

守业公司后期不须要这种简单，间接上 zk，弄一个界面治理 zk 的内容，记录一下所有人的操作日志，程序直连 zk，或者或者用 Qconf 等基于 zk 优化后的计划。

15、公布零碎 / 部署零碎

从软件生产的层面看，代码到最终服务的典型流程如图 8 所示：

图 8，流程图

从上图中能够看出，从开发人员写下代码到服务最终用户是一个漫长过程，整体能够分成三个阶段：

• 从代码（Code）到成品库（Artifact）这个阶段次要对开发人员的代码做继续构建并把构建产生的制品集中管理，是为部署零碎筹备输出内容的阶段。
• 从制品到可运行服务 这个阶段次要实现制品部署到指定环境，是部署零碎的最根本工作内容。
• 从开发环境到最终生产环境 这个阶段次要实现一次变更在不同环境的迁徙，是部署零碎上线最终服务的外围能力。

公布系统集成了制品治理，公布流程，权限管制，线上环境版本变更，灰度公布，线上服务回滚等几方面的内容，是开发人员工作结晶最终出现的重要通道。开源的我的项目中没有齐全满足的我的项目，如果只是 Web 类我的项目，Walle、Piplin 都是可用的，然而性能不太满足，守业初期能够集成 Jenkins + Gitlab + Walle（能够思考两天工夫欠缺一下），以上计划根本包含制品治理，公布流程，权限管制，线上环境版本变更，灰度公布（须要本人实现），线上服务回滚等性能。

16、跳板机

跳板机面对的是需要是要有一种能满足角色治理与受权审批、信息资源访问控制、操作记录和审计、零碎变更和保护管制要求，并生成一些统计报表配合治理标准来一直晋升 IT 内控的合规性，能对运维人员操作行为的进行管制和审计，对误操作、违规操作导致的操作事变，疾速定位起因和责任人。其功能模块个别包含：帐户治理、认证治理、受权治理、审计治理等等。

开源我的项目中，Jumpserver 可能实现跳板机常见需要，如受权、用户治理、服务器根本信息记录等，同时又可批量执行脚本等性能；其中录像回放、命令搜寻、实时监控等特点，又能帮忙运维人员回溯操作历史，不便查找操作痕迹，便于管理其余人员对服务器的操作控制。

17、机器治理

机器治理的工具抉择的考量能够蕴含以下三个方面：

1. 是否简略，是否须要每台机器部署 Agent（客户端）
2. 语言的抉择（Puppet/Chef vs Ansible/SaltStack）开源技术，不看官网不足以纯熟，不懂源码不足以精通；Puppet、Chef 基于 Ruby 开发，Ansible、SaltStack 基于 Python 开发的
3. 速度的抉择（Ansible vs SaltStack）Ansible 基于 SSH 协定传输数据，SaltStack 应用音讯队列 zeroMQ 传输数据；大规模并发的能力对于几十台 – 200 台规模的兄弟来讲，Ansible 的性能也可承受，如果一次操作上千台，用 salt 好一些。

如图 9 所示：

图 9，机器管理软件比照

个别守业公司抉择 Ansible 能解决大部问题，其简略，不须要装置额定的客户端，能够从命令行来运行，不须要应用配置文件。至于比较复杂的工作，Ansible 配置通过名为 Playbook 的配置文件中的 YAML 语法来加以解决。Playbook 还能够应用模板来扩大其性能。

守业公司的抉择

1、抉择适合的语言

• 抉择团队相熟的 / 能掌控的，守业公司人少事多，无太多冗余让研发团队相熟新的语言，能疾速上手，能疾速出活，出了问题能疾速解决的问题的语言才是好的抉择。
• 抉择更古代一些的，这里的古代是指语言自身曾经实现一些之前须要非凡解决的个性，比方内存治理，线程等等。
• 抉择开源轮子多的或者社区活跃度高的，这个准则是为了保障在开发过程中缩小投入，有稳固牢靠的轮子能够应用，遇到问题能够在网上疾速搜寻到答案。
• 抉择好招人的 一门适合的语言会让守业团队缩小招聘的老本，疾速招到适合的人。
• 抉择能让人有趣味的 与下面一点相干，让人感兴趣，在前面留人时有用。

2、抉择适合的组件和云服务商

• 抉择靠谱的云服务商；
• 抉择云服务商的组件；
• 抉择成熟的开源组件，而不是最新出的组件；
• 抉择采纳在一线互联网公司落地并且开源的，且在社区内造成良好口碑的产品；
• 开源社区活跃度；

抉择靠谱的云服务商，其实这是一个伪命题，因为哪个服务商都不靠谱，他们所承诺的那些可用性问题基本上都会在你的身上产生，这里咱们还是须要本人做一些工作，比方多服务商备份，如用 CDN，你肯定不要只选一家，至多选两家，一个是灾备，放弃后盾切换的能力，另一个是多点笼罩，不同的服务商在 CDN 节点上的资源是不一样的。

抉择了云服务商当前，就会有很多的产品你能够抉择了，比拟存储，队列这些都会有现成的产品，这个时候就纠结了，是用呢？还是本人在云主机上搭呢？在这里我的倡议是后期先用云服务商的，大了后再本人搞，这样会少掉很多运维的事件，然而这里要多理解一下云服务商的组件个性以及一些坑，比方他们内网会常常断开，他们降级也会闪断，所以在业务侧要做好容错和躲避。

对于开源组件，尽可能抉择成熟的，成熟的组件经验了工夫的考验，根本不会出大的问题，并且有成套的配套工具，出了问题在网上也能够很快的找到答案，你所遇到的坑基本上都有人踩过了。

3、制订流程和标准

• 制订开发的标准，代码及代码分支治理标准，关键性代码仅多数人有权限；
• 制订公布流程标准，从公布零碎落地；
• 制订运维标准；
• 制订数据库操作标准，收拢数据库操作权限；
• 制订告警解决流程，做到告警有人看有人解决；
• 制订汇报机制，晨会 / 周报；

4、自研和选型适合的辅助零碎

所有的流程和标准都须要用零碎来固化，否则就是海市蜃楼，如何抉择这些零碎呢？参照上个章节咱们那些开源的，比照一下抉择的语言，组件之类的，抉择一个最合适的即可。

比方项目管理的，看下本人是什么类型的公司，开发的节奏是怎么的，瀑布，麻利的 按我的项目划分，还是按客户划分等等，平时是按我的项目组织还是按工作组织等等。

比方日志零碎，之前是打的文本，那么上一个 ELK，规范化一些日志组件，基本上很长一段时间内不必思考日志零碎的问题，最多拆分一下或者扩容一下。等到组织大了，本人搞一个日志零碎。

比方代码治理，我的项目管理系统这些都放内网，平安，在互联网公司来说，属于命根子了，命根子的货色还是放在他人拿不到或很难拿到的中央会比拟靠谱一些。

5、抉择过程中须要思考的问题

技术栈的抉择有点像做出了某种承诺，在肯定的工夫内这种承诺没法扭转，于是咱们须要在抉择的时候有一些思考。

看后面内容，有一个词呈现了三次，适合，抉择是适合的，不是最好，也不是最新，是最合适，适宜是针对当下，这种抉择是最合适的吗？比方用 Go 这条线的货色，技术比拟新，业界组件储备够吗？组织内的人员储备够吗？学习老本多少？写进去的货色能满足业务性能要求吗？能满足工夫要求吗？

向将来看一眼，在一年到三年内，咱们须要做出扭转吗？技术栈要做根本性的扭转吗？如果组织倒退很快，在 200 人，500 人时，现有的技术栈是否须要大动？

守业过程中须要思考老本，这里的老本不仅仅是破费多少钱，付出多少工资，有时更重要的是工夫老本，很多业务在守业时大家拼的就是工夫，就是一个工夫窗，过了就没你什么事儿了。

基于云的守业公司后盾技术架构

联合下面内容的考量，在对一个个零碎和组件的做选型之后，以云服务为根底，一个守业公司的后盾技术架构如图 10 所示：

图 10，后盾技术架构

参考资料

[1] http://database.51cto.com/art…

[2] https://zh.wikipedia.org/wiki…

[3] https://prometheus.io/docs/in…

[4] http://deadline.top/2016/11/23 / 配置核心那点事 /

[5] http://blog.fit2cloud.com/201…