我们会用到的一些言语的合集，而且只是言语层面的一局部，就整个后台技术栈来说，这只是一个开端，从言语开端，还有很多很多的内容。今天要说的后台是大后台的概念，放在效劳器上的东西都属于后台的东西，比方运用的框架，言语，数据库，效劳，操作系统等等。
整个后台技术栈我的了解包括 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，即至少要满足以下五点的新型关系数据库：
完好地支持 SQL，支持 JOIN / GROUP BY /子查询等复杂 SQL 查询。支持传统数据标配的 ACID 事务，支持强隔离级别。具有弹性伸缩的才能，扩容缩容关于业务层完整透明。真正的高可用，异地多活、毛病恢复的过程不需求人为的接入，系统可以自动地容灾和停止强分歧的数据恢复。具备一定的大数据剖析才能。
传统关系数据库用得最多的是 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/products/feature-comparison/。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、机器管理
机器管理的工具选择的考量能够包含以下三个方面：
能否简单，能否需求每台机器部署 Agent（客户端）言语的选择（Puppet/Chef vs Ansible/SaltStack ）开源技术，不看官网缺乏以纯熟，不懂源码缺乏以通晓；Puppet、Chef 基于 Ruby 开发，Ansible、SaltStack 基于 Python 开发的速度的选择（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所示：
相关推荐
