一个牛逼的创业公司后台技术栈搭建方案

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

图 1

有点眼晕，以下只是我们会用到的一些语言的合集，而且只是语言层面的一部分，就整个后台技术栈来说，这只是一个开始，从语言开始，还有很多很多的内容。

今天要说的后台是大后台的概念，放在服务器上的东西都属于后台的东西，比如使用的框架，语言，数据库，服务，操作系统等等。

整个后台技术栈，我的理解包括四个层面的内容：

• 语言：用了哪些开发语言，如：C++/Java/Go/PHP/Python/Ruby 等等。

• 组件：用了哪些组件，如：MQ 组件，数据库组件等等。

• 流程：怎样的流程和规范，如：开发流程，项目流程，发布流程，监控告警流程，代码规范等等。

• 系统：系统化建设，上面的流程需要有系统来保证，如：规范发布流程的发布系统，代码管理系统等等。

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

图 2：后台技术栈结构

以上的这些内容都需要我们从零开始搭建，在创业公司，没有大公司那些完善的基础设施，需要我们从开源界，从云服务商甚至有些需要自己去组合，去拼装，去开发一个适合自己的组件或系统以达成我们的目标。

咱们一个个系统和组件的做选型，最终形成我们的后台技术栈。

项目管理软件是整个业务的需求，问题，流程等等的集中地，大家的跨部门沟通协同大多依赖于项目管理工具。

有一些 SaaS 的项目管理服务可以使用，但是很多时间不满足需求，此时我们可以选择一些开源的项目，这些项目本身有一定的定制能力，有丰富的插件可以使用。

一般的创业公司需求基本上都能得到满足，常用的项目如下：

• Redmine：用 Ruby 开发的，有较多的插件可以使用，能自定义字段，集成了项目管理，Bug 问题跟踪，WiKi 等功能，不过好多插件 N 年没有更新了。

• Phabricator：用 PHP 开发的，Facebook 之前的内部工具，开发这工具的哥们离职后自己搞了一个公司专门做这个软件，集成了代码托管， Code Review，任务管理，文档管理，问题跟踪等功能，强烈推荐较敏捷的团队使用。

• Jira：用 Java 开发的，有用户故事，Task 拆分，燃尽图等等，可以做项目管理，也可以应用于跨部门沟通场景，较强大。

• 悟空 CRM ：这个不是项目管理，这个是客户管理，之所以在这里提出来，是因为在 To B 的创业公司里面，往往是以客户为核心来做事情的，可以将项目管理和问题跟进的在悟空 CRM 上面来做。

  它的开源版本已经基本实现了 CRM 的核心功能，还带有一个任务管理功能，用于问题跟进，不过用这个的话，还是需要另一个项目管理的软件协助，顺便说一嘴，这个系统的代码写得很难维护，只能适用于客户规模小（1 万以内）时。
  

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

• 阿里万网：阿里 2014 年收购了万网，整合了其域名服务，最终形成了现在的阿里万网，其中就包含 DNS 这块的服务。

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

如果你的业务是在国内，主要就是这两家，选 一个就好，像今日头条这样的企业用的也是 DNSPod 的服务，除非一些特殊的原因才需要自建，比如一些 CDN 厂商，或者对区域有特殊限制的。

要实惠一点用阿里最便宜的基础版就好了，要成功率高一些，还是用 DNSPod 的贵的那种。

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

如果是线上产品，DNS 强烈建议用付费版，阿里的那几十块钱的付费版基本可以满足需求。

如果还需要一些按省份或按区域调试的逻辑，则需要加钱，一年也就几百块，省钱省力。

如果是国外，优先选择亚马逊，如果需要国内外互通并且有自己的 App 的话，建议还是自己实现一些容灾逻辑或者智能调度。

因为没有一个现成的 DNS 服务能同时较好的满足国内外场景，或者用多个域名，不同的域名走不同的 DNS 。

LB（负载均衡）是一个通用服务，一般云厂商的 LB 服务基本都有如下功能：

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

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

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

• 健康检查

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

CDN 现在已经是一个很红很红的市场，基本上只能挣一些辛苦钱，都是贴着成本在卖。

国内以网宿为龙头，他们家占据整个国内市场份额的 40% 以上，后面就是腾讯，阿里。网宿有很大一部分是因为直播的兴起而崛起。

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

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

就创业公司来说，CDN 用腾讯云或阿里云即可，其相关系统较完善，能轻松接入，网宿在系统支持层面相对较弱一些，而且还贵一些。

并且，当流量上来后，CDN 不能只用一家，需要用多家，不同的 CDN 在全国的节点覆盖不一样。

而且针对不同的客户云厂商内部有些区分客户集群，并不是全节点覆盖（但有些云厂商说自己是全网节点），除了节点覆盖的问题，多 CDN 也在一定程度上起到容灾的作用。

维基百科对 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 方式的存储，被用在分享配置和服务发现中。两个著名的项目使用了它：Kubernetes 和 Cloud Foundry。

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

• Apache ZooKeeper：一个广泛使用、高性能的针对分布式应用的协调服务。Apache ZooKeeper 本来是 Hadoop 的子工程，现在已经是顶级工程了。

除此之外也可以自己实现服务实现，或者用 Redis 也行，只是需要自己实现高可用性。

关系数据库分为两种，一种是传统关系数据库，如 Oracle，MySQL，Maria，DB2，PostgreSQL 等等。

另一种是 NewSQL，即至少要满足以下五点的新型关系数据库：

• 完整地支持 SQL，支持 JOIN / GROUP BY /子查询等复杂 SQL 查询。

• 支持传统数据标配的 ACID 事务，支持强隔离级别。

• 具有弹性伸缩的能力，扩容缩容对于业务层完全透明。

• 真正的高可用，异地多活、故障恢复的过程不需要人为的接入，系统能够自动地容灾和进行强一致的数据恢复。

• 具备一定的大数据分析能力。

传统关系数据库用得最多的是 MySQL，因为成熟，稳定，一些基本的需求都能满足，在一定数据量级之前基本单机传统数据库都可以搞定。

而且现在较多的开源系统都是基于 MySQL，开箱即用，再加上主从同步和前端缓存，百万 PV 的应用都可以搞定了。

不过 CentOS 7 已经放弃了 MySQL，而改使用 MariaDB。MariaDB 数据库管理系统是 MySQL 的一个分支，主要由开源社区在维护，采用 GPL 授权许可。

开发这个分支的原因之一是：甲骨文公司收购了 MySQL 后，有将 MySQL 闭源的潜在风险，因此社区采用分支的方式来避开这个风险。

在 Google 发布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 之后，业界开始流行起 NewSQL。

于是有了 CockroachDB，然后有了奇叔公司的 TiDB。国内已经有比较多的公司使用 TiDB，之前在创业公司时在大数据分析时已经开始应用 TiDB，当时应用的主要原因是 MySQL 要使用分库分表，逻辑开发比较复杂，扩展性不够。

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

常见 NoSQL 有四个类型：

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

• 列式，以列簇式存储，将同一列数据存在一起，常见于分布式的文件系统，其中以 Hbase，Cassandra 为代表。

  Cassandra 多用于写多读少的场景，国内用得比较多的有 360，大概 1500 台机器的集群，国外大规模使用的公司比较多，如 eBay，Instagram，Apple 和沃尔玛等等。

• 文档，数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。性能介于 KV 和关系数据库之间，它的灵感来自 Lotus Notes，常见的有 MongoDB，CouchDB 等等。

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

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

在实际应用场景中，何时使用关系数据库，何时使用 NoSQL，使用哪种类型的数据库，这是我们在做架构选型时一个非常重要的考量，甚至会影响整个架构的方案。

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