[转]从零开始搭建创业公司后台技术栈

此为转载文章，仅作记录使用，方便往后查看，原文连接：http://www.phppan.com/2018/04/svr-stack/

 

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

[图1]

有点眼晕，以上只是咱们会用到的一些语言的合集，并且只是语言层面的一部分，就整个后台技术栈来讲，这只是一个开始，从语言开始，还有不少不少的内容。今天要说的后台是大后台的概念，放在服务器上的东西都属于后台的东西，好比使用的框架，语言，数据库，服务，操做系统等等，整个后台技术栈个人理解包括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万之内）时。

二、DNS

DNS 是一个很通用的服务，创业公司基本上选择一个合适的云厂商就好了，国内主要是两家：

• 阿里万网：阿里 2014 年收购了万网，整合了其域名服务，最终造成了如今的阿里万网，其中就包含 DNS 这块的服务；

• 腾讯 DNSPod: 腾讯 2012 年以 4000 万收购 DNSPod 100% 股份，主要提供域名解析和一些防御功能；

若是你的业务是在国内，主要就是这两家，选 一个就好，像今日头条这样的企业用的也是 DNSPod 的服务，除非一些特殊的缘由才须要自建，好比一些 CDN 厂商，或者对区域有特殊限制的。要实惠一点用阿里最便宜的基础版就行了，要成功率高一些，仍是用DNSPod 的贵的那种。

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

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

若是是国外，优先选择亚马逊，若是须要国内外互通而且有本身的 APP 的话，建议仍是本身实现一些容灾逻辑或者智能调度，由于没有一个现成的 DNS 服务能同时较好的知足国内外场景，或者用多个域名，不一样的域名走不一样的 DNS 。

三、LB(负载均衡)

LB(负载均衡)是一个通用服务，通常云厂商的 LB 服务基本都会以下功能：

• 支持四层协议请求（包括 TCP、UDP 协议）;

• 支持七层协议请求（包括 HTTP、HTTPS 协议）;

• 集中化的证书管理系统支持 HTTPS 协议;

• 健康检查;

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

四、CDN

CDN 如今已是一个很红很红的市场，基本上只能挣一些辛苦钱，都是贴着成本在卖。国内以网宿为龙头，他们家占据整个国内市场份额的40%以上，后面就是腾讯，阿里。网宿有很大一部分是由于直播的兴起而崛起。

国外，Amazon 和 Akamai 合起来占比大概在 50%，曾经的国际市场老大 Akamai 拥有全球超一半的份额，在 Amazon CDN入局后，份额跌去了将近 20%，众多中小企业都转向后者，Akamai 也是无能为力。

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

就创业公司来讲，CDN 用腾讯云或阿里云便可，其相关系统较完善，能轻松接入，网宿在系统支持层面相对较弱一些，并且还贵一些。而且，当流量上来后，CDN 不能只用一家，须要用多家，不一样的 CDN 在全国的节点覆盖不同，并且针对不一样的客户云厂商内部有些区分客户集群，并非全节点覆盖（但有些云厂商说本身是全网节点），除了节点覆盖的问题，多 CDN 也在必定程度上起到容灾的做用。

五、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 框架，能够参考学习一下。

六、名字发现/服务发现

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

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

所谓服务端发现模式是指客户端经过一个负载均衡器向服务发送请求，负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。如今经常使用的负载均衡器都是此类模式，经常使用于微服务中。

全部的名字发现和服务发现都要依赖于一个可用性很是高的服务注册表，业界经常使用的服务注册表有以下三个：

• etcd，一个高可用、分布式、一致性、key-value方式的存储，被用在分享配置和服务发现中。两个著名的项目使用了它：k8s和Cloud Foundry。

• consul，一个发现和配置服务的工具，为客户端注册和发现服务提供了API，Consul还能够经过执行健康检查决定服务的可用性。

• Apache Zookeeper，是一个普遍使用、高性能的针对分布式应用的协调服务。Apache Zookeeper原本是 Hadoop 的子工程，如今已是顶级工程了。

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

七、关系数据库

关系数据库分为两种，一种是传统关系数据，如 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 后，有将 MySQ L闭源的潜在风险，所以社区采用分支的方式来避开这个风险。

在 Google 发布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 以后，业界开始流行起 NewSQL。因而有了 CockroachDB，因而有了 奇叔公司的 TiDB。国内已经有比较多的公司使用 TiDB，以前在创业公司时在大数据分析时已经开始应用 TiDB，当时应用的主要缘由是 MySQL 要使用分库分表，逻辑开发比较复杂，扩展性不够。

八、NoSQL

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

常见 NoSQL 有4个类型：

1. 键值，适用于内容缓存，适合混合工做负载并发高扩展要求大的数据集，其优势是简单，查询速度快，缺点是缺乏结构化数据，常见的有 Redis, Memcache, BerkeleyDB 和 Voldemort 等等；

2. 列式，以列簇式存储，将同一列数据存在一块儿，常见于分布式的文件系统，其中以 Hbase，Cassandra 为表明。Cassandra 多用于写多读少的场景，国内用得比较多的有 360，大概 1500 台机器的集群，国外大规模使用的公司比较多，如 Ebay，Instagram，Apple 和沃尔玛等等；

3. 文档，数据存储方案很是适用承载大量不相关且结构差异很大的复杂信息。性能介于 kv 和关系数据库之间，它的灵感来于 lotus notes，常见的有 MongoDB，CouchDB 等等；

4. 图形，图形数据库擅长处理任何涉及关系的情况。社交网络，推荐系统等。专一于构建关系图谱，须要对整个图作计算才能得出结果，不容易作分布式的集群方案，常见的有 Neo4J，InfoGrid 等。

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

在实际应用场景中，什么时候使用关系数据库，什么时候使用 NoSQL，使用哪一种类型的数据库，这是咱们在作架构选型时一个很是重要的考量，甚至会影响整个架构的方案。

九、消息中间件

消息中间件在后台系统中是必不可少的一个组件，通常咱们会在如下场景中使用消息中间件：

• 异步处理：异步处理是使用消息中间件的一个主要缘由，在工做中最多见的异步场景有用户注册成功后须要发送注册成功邮件、缓存过时时先返回老的数据，而后异步更新缓存、异步写日志等等；经过异步处理，能够减小主流程的等待响应时间，让非主流程或者非重要业务经过消息中间件作集中的异步处理。

• 系统解耦：好比在电商系统中，当用户成功支付完成订单后，须要将支付结果给通知ERP系统、发票系统、WMS、推荐系统、搜索系统、风控系统等进行业务处理；这些业务处理不须要实时处理、不须要强一致，只须要最终一致性便可，所以能够经过消息中间件进行系统解耦。经过这种系统解耦还能够应对将来不明确的系统需求。

• 削峰填谷：当系统遇到大流量时，监控图上会看到一个一个的山峰样的流量图，经过使用消息中间件将大流量的请求放入队列，经过消费者程序将队列中的处理请求慢慢消化，达到消峰填谷的效果。最典型的场景是秒杀系统，在电商的秒杀系统中下单服务每每会是系统的瓶颈，由于下单须要对库存等作数据库操做，须要保证强一致性，此时使用消息中间件进行下单排队和流控，让下单服务慢慢把队列中的单处理完，保护下单服务，以达到削峰填谷的做用。

业界消息中间件是一个很是通用的东西，你们在作选型时有使用开源的，也有本身造轮子的，甚至有直接用 MySQL 或 Redis 作队列的，关键看是否知足你的需求，若是是使用开源的项目，如下的表格在选型时能够参考：

[图3]

以上图的纬度为：名字 成熟度所属社区/公司 文档 受权方式 开发语言支持的协议 客户端支持的语言 性能 持久化 事务 集群 负载均衡 管理界面 部署方式 评价

10 、代 码管理

代码是互联网创业公司的命脉之一，代码管理很重要，常见的考量点包括两块：

• 安全和权限管理，将代码放到内网而且对于关系公司命脉的核心代码作严格的代码控制和机器的物理隔离；

• 代码管理工具，Git 做为代码管理的不二之选，你值得拥有。Gitlab 是当今最火的开源 Git 托管服务端，没有之一，虽然有企业版，可是其社区版基本能知足咱们大部分需求，结合 Gerrit 作 Code review，基本就完美了。固然 Gitlab 也有代码对比，但没Gerrit 直观。Gerrit 比 Gitlab 提供了更好的代码检查界面与主线管理体验，更适合在对代码质量有高要求的文化下使用。

十一、持续集成

持续集成简，称 CI(continuous integration)， 是一种软件开发实践，即团队开发成员常常集成他们的工做，天天可能会发生屡次集成。每次集成都经过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。持续集成为研发流程提供了代码分支管理/比对、编译、检查、发布物输出等基础工做，为测试的覆盖率版本编译、生成等提供统一支持。

业界免费的持续集成工具中系统咱们有以下一些选择：

• Jenkins：Jjava写的 有强大的插件机制，MIT协议开源 （免费，定制化程度高，它能够在多台机器上进行分布式地构建和负载测试）。Jenkins能够算是无所不能，基本没有 Jenkins 作不了的，不管从小型团队到大型团队 Jenkins 均可以搞定。 不过若是要大规模使用，仍是须要有人力来学习和维护。

• TeamCity： TeamCity与Jenkins相比使用更加友好，也是一个高度可定制化的平台。可是用的人多了，TeamCity就要收费了。

• Strider： Strider 是一个开源的持续集成和部署平台，使用 Node.js 实现，存储使用的是 MongoDB，BSD 许可证，概念上相似 Travis 和Jenkins。

• GitLabCI：从GitLab8.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发行版。

十二、日志系统

日志系统通常包括打日志，采集，中转，收集，存储，分析，呈现，搜索还有分发等。一些特殊的如染色，全链条跟踪或者监控均可能须要依赖于日志系统实现。日志系统的建设不只仅是工具的建设，还有规范和组件的建设，最好一些基本的日志在框架和组件层面加就好了，好比全连接跟踪之类的。

对于常规日志系统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 追求的是数据的多样性，两者结合起来简直完美。

1三、监控系统

监控系统只包含与后台相关的，这里主要是两块，一个是操做系统层的监控，好比机器负载，IO，网络流量，CPU，内存等操做系统指标的监控。另外一个是服务质量和业务质量的监控，好比服务的可用性，成功率，失败率，容量，QPS 等等。常见业务的监控系统先有操做系统层面的监控（这部分较成熟），而后扩展出其它监控，如 zabbix，小米的 open-falcon，也有一出来就是二者都支持的，如 prometheu s。若是对业务监控要求比较高一些，在创业选型中建议能够优先考虑 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 定时去抓取 metric s数据，每一个抓取目标须要暴露一个 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 )，能够知足大部分中小团队的监控需求。

1四、配置系统

随着程序功能的日益复杂，程序的配置日益增多：各类功能的开关、降级开关，灰度开关，参数的配置、服务器的地址、数据库配置等等，除此以外，对后台程序配置的要求也愈来愈高：配置修改后实时生效，灰度发布，分环境、分用户，分集群管理配置，完善的权限、审核机制等等，在这样的大环境下，传统的经过配置文件、数据库等方式已经愈来愈没法知足开发人员对配置管理的需求，业界有以下两种方案：

• 基于 zk 和 etcd，支持界面和 api ，用数据库来保存版本历史，预案，走审核流程，最后下发到 zk 或 etcd 这种有推送能力的存储里（服务注册自己也是用 zk 或 etcd，选型就一块了）。客户端都直接和 zk 或 etcd 打交道。至于灰度发布，各家不一样，有一种实现是同时发布一个须要灰度的 IP 列表，客户端监听到配置节点变化时，对比一下本身是否属于该列表。PHP 这种无状态的语言和其余 zk/etcd 不支持的语言，只好本身在客户端的机器上起一个 Agent 来监听变化，再写到配置文件或共享内存，如 360 的 Qconf。

• 基于运维自动化的配置文件的推送，审核流程，配置数据管理和方案一相似，下发时生成配置文件，基于运维自动化工具如Puppet，Ansible 推送到每一个客户端，而应用则定时从新读取这个外部的配置文件，灰度发布在下发配置时指定IP列表。

创业公司前期不须要这种复杂，直接上 zk，弄一个界面管理 zk 的内容，记录一下全部人的操做日志，程序直连 zk，或者或者用Qconf 等基于 zk 优化后的方案。

1五、发布系统/部署系统

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

[图8 流程图]

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

• 从代码（Code）到成品库（Artifact）这个阶段主要对开发人员的代码作持续构建并把构建产生的制品集中管理，是为部署系统准备输入内容的阶段。

• 从制品到可运行服务 这个阶段主要完成制品部署到指定环境，是部署系统的最基本工做内容。

• 从开发环境到最终生产环境 这个阶段主要完成一次变动在不一样环境的迁移，是部署系统上线最终服务的核心能力。

发布系统集成了制品管理，发布流程，权限控制，线上环境版本变动，灰度发布，线上服务回滚等几方面的内容，是开发人员工做结晶最终呈现的重要通道。开源的项目中没有彻底知足的项目，若是只是 Web 类项目，Walle、Piplin 都是可用的，可是功能不太知足，创业初期能够集成 Jenkins + Gitlab + Walle (能够考虑两天时间完善一下)，以上方案基本包括 制品管理，发布流程，权限控制，线上环境版本变动，灰度发布（须要本身实现），线上服务回滚等功能。

1六、跳板机

跳板机面对的是需求是要有一种能知足角色管理与受权审批、信息资源访问控制、操做记录和审计、系统变动和维护控制要求，并生成一些统计报表配合管理规范来不断提高IT内控的合规性，能对运维人员操做行为的进行控制和审计，对误操做、违规操做致使的操做事故，快速定位缘由和责任人。其功能模块通常包括：账户管理、认证管理、受权管理、审计管理等等

开源项目中，Jumpserver 可以实现跳板机常见需求，如受权、用户管理、服务器基本信息记录等，同时又可批量执行脚本等功能；其中录像回放、命令搜索、实时监控等特色，又能帮助运维人员回溯操做历史，方便查找操做痕迹，便于管理其余人员对服务器的操做控制。

1七、机器管理

机器管理的工具选择的考量能够包含如下三个方面：

1. 是否简单，是否须要每台机器部署agent（客户端）

2. 语言的选择（puppet/chef vsansible/saltstack）开源技术，不看官网不足以熟练，不懂源码不足以精通；Puppet、Chef基于Ruby开发，ansible、saltstack基于python开发的

3. 速度的选择(ansiblevssaltstack) ansible基于SSH协议传输数据，Saltstack使用消息队列zeroMQ传输数据；大规模并发的能力对于几十台-200台规模的兄弟来说，ansible的性能也可接受，若是一次操做上千台，用salt好一些。

如图9所示：

[图9 机器管理软件对比]

通常创业公司选择 Ansible 能解决大部问题，其简单，不须要安装额外的客户端，能够从命令行来运行，不须要使用配置文件。至于比较复杂的任务，Ansible 配置经过名为 Playbook 的配置文件中的 YAML 语法来加以处理。Playbook 还可使用模板来扩展其功能。

2、创业公司的选择

一、选择合适的语言

• 选择团队熟悉的/能掌控的，创业公司人少事多，无太多冗余让研发团队熟悉新的语言，能快速上手，能快速出活，出了问题能快速解决的问题的语言才是好的选择。

• 选择更现代一些的，这里的现代是指语言自己已经完成一些以前须要特殊处理的特性，好比内存管理，线程等等。

• 选择开源轮子多的或者社区活跃度高的，这个原则是为了保证在开发过程当中减小投入，有稳定可靠的轮子可使用，遇到问题能够在网上快速搜索到答案。

• 选择好招人的 一门合适的语言会让创业团队减小招聘的成本，快速招到合适的人。

• 选择能让人有兴趣的 与上面一点相关，让人感兴趣，在后面留人时有用。

二、选择合适的组件和云服务商

• 选择靠谱的云服务商；

• 选择云服务商的组件；

• 选择成熟的开源组件，而不是最新出的组件；

• 选择采用在一线互联网公司落地而且开源的，且在社区内造成良好口碑的产品；

• 开源社区活跃度；

选择靠谱的云服务商，其实这是一个伪命题，由于哪一个服务商都不靠谱，他们所承诺的那些可用性问题基本上都会在你的身上发生，这里咱们仍是须要本身作一些工做，好比多服务商备份，如用CDN，你必定不要只选一家，至少选两家，一个是灾备，保持后台切换的能力，另外一个是多点覆盖，不一样的服务商在CDN节点上的资源是不同的。

选择了云服务商之后，就会有不少的产品你能够选择了，比较存储，队列这些都会有现成的产品，这个时候就纠结了，是用呢？仍是本身在云主机上搭呢？在这里个人建议是前期先用云服务商的，大了后再本身搞，这样会少掉不少运维的事情，可是这里要多了解一下云服务商的组件特性以及一些坑，好比他们内网会常常断开，他们升级也会闪断，因此在业务侧要作好容错和规避。

关于开源组件，尽量选择成熟的，成熟的组件经历了时间的考验，基本不会出大的问题，而且有成套的配套工具，出了问题在网上也能够很快的找到答案，你所遇到的坑基本上都有人踩过了。

三、制定流程和规范

• 制定开发的规范，代码及代码分支管理规范，关键性代码仅少数人有权限；

• 制定发布流程规范，从发布系统落地；

• 制定运维规范；

• 制定数据库操做规范，收拢数据库操做权限；

• 制定告警处理流程，作到告警有人看有人处理；

• 制定汇报机制，晨会/周报；

四、自研和选型合适的辅助系统

全部的流程和规范都须要用系统来固化，不然就是空中楼阁，如何选择这些系统呢？参照上个章节我们那些开源的，对比一下选择的语言，组件之类的，选择一个最合适的便可。

好比项目管理的，看下本身是什么类型的公司，开发的节奏是怎样的，瀑布，敏捷的 按项目划分，仍是按客户划分等等，平时是按项目组织仍是按任务组织等等

好比日志系统，以前是打的文本，那么上一个elk，规范化一些日志组件，基本上很长一段时间内不用考虑日志系统的问题，最多拆分一下或者扩容一下。等到组织大了，本身搞一个日志系统。

好比代码管理，项目管理系统这些都放内网，安全，在互联网公司来讲，属于命脉了，命脉的东西仍是放在别人拿不到或很难拿到的地方会比较靠谱一些。

五、选择过程当中须要思考的问题

技术栈的选择有点像作出了某种承诺，在必定的时间内这种承诺无法改变，因而咱们须要在选择的时候有一些思考。

看前面内容，有一个词出现了三次，合适，选择是合适的，不是最好，也不是最新，是最合适，适合是针对当下，这种选择是最合适的吗？好比用 Go 这条线的东西，技术比较新，业界组件储备够吗？组织内的人员储备够吗？学习成本多少？写出来的东西能知足业务性能要求吗？能知足时间要求吗？

向将来看一眼，在一年到三年内，咱们须要作出改变吗？技术栈要作根本性的改变吗？若是组织发展很快，在 200 人，500 人时，现有的技术栈是否须要大动？

创业过程当中须要考虑成本，这里的成本不只仅是花费多少钱，付出多少工资，有时更重要的是时间成本，不少业务在创业时你们拼的就是时间，就是一个时间窗，过了就没你什么事儿了。

3、基于云的创业公司后台技术架构

结合上面内容的考量，在对一个个系统和组件的作选型以后，以云服务为基础，一个创业公司的后台技术架构如图10所示：

[图10 后台技术架构]

参考资料

http://database.51cto.com/art/201109/291781.htm

https://zh.wikipedia.org/wiki/Kafka

https://prometheus.io/docs/introduction/overview/

http://deadline.top/2016/11/23/配置中心那点事/

http://blog.fit2cloud.com/2016/01/26/deployment-system.html