All posts by dotte

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

四月 23, 2018JAVA, Web, 架构技术栈dotte

有点眼晕，以上只是我们会用到的一些语言的合集，而且只是语言层面的一部分，就整个后台技术栈来说，这只是一个开始，从语言开始，还有很多很多的内容。今天要说的后台是大后台的概念，放在服务器上的东西都属于后台的东西，比如使用的框架，语言，数据库，服务，操作系统等等，整个后台技术栈我的理解包括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方式的存储，被用在分享配置和服务发现中。两个著名的项目使用了它：k8s和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 后，有将 MySQ L闭源的潜在风险，因此社区采用分支的方式来避开这个风险。

在 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：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发行版。

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，也有一出来就是两者都支持的，如 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 )，可以满足大部分中小团队的监控需求。

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 vsansible/saltstack）开源技术，不看官网不足以熟练，不懂源码不足以精通；Puppet、Chef基于Ruby开发，ansible、saltstack基于python开发的
速度的选择(ansiblevssaltstack) 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 后台技术架构]

参考资料

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

from:http://www.phppan.com/2018/04/svr-stack/

HTTP协议冷知识大全

三月 29, 2018WebCORS, http, JSONPdotte

如果不用HTTPS，HTTP协议如何安全的传输密码信息？

HTTP协议是纯文本协议，没有任何加密措施。通过HTTP协议传输的数据都可以在网络上被完全监听。如果用户登陆时将用户名和密码直接明文通过HTTP协议传输过去了，那么密码可能会被黑客窃取。
一种方法是使用非对称加密。GET登陆页面时，将公钥以Javascript变量的形式暴露给浏览器。然后用公钥对用户的密码加密后，再将密码密文、用户名和公钥一起发送给服务器。服务器会提前存储公钥和私钥的映射信息，通过客户端发过来的公钥就可以查出对应的私钥，然后对密码密文进行解密就可以还原出密码的明文。
为了加强公钥私钥的安全性，服务器应该动态生成公钥私钥对，并且使用后立即销毁。但是动态生成又是非常耗费计算资源的，所以一般服务器会选择Pool方法提供有限数量的公钥私钥对池，然后每隔一段时间刷新一次Pool。

文件路径攻击

很多操作系统都会使用..符号表示上层目录。如果黑客在URL的路径里面使用..符号引用上层目录，而服务器没有做好防范的话就有可能导致黑客可以直接访问权限之外的文件。比如使用多级..符号就可以引用到根目录，进一步就可以访问任意文件。
所以很多服务器都禁止在URL路径里出现..符号以避免被攻击。
文件路径攻击也是很多黑客非常喜爱使用的攻击方法之一。如果你的服务器有一定的访问量，打开你的nginx日志，你就会偶尔发现有一些奇怪的URL里面有一堆..符号，这种URL的出现就表示网络上的黑客正在尝试攻击你的服务器。

DNS欺骗

HTTP协议严重依赖于DNS域名解析。任意一个域名类网址的访问都需要经过域名解析的过程得到目标服务的IP地址才能成功继续下去。
如果掌管DNS服务的运营商作恶将域名解析到不正确的IP，指向一个钓鱼的网页服务。用户如果没有觉察，就可能会将自己的敏感信息提交给冒牌的服务器。

谨慎使用外部的HTTP代理

HTTP代理作为客户端到服务器之间的中间路由节点，它起到传话人和翻译官的角色。
如果这个翻译官不靠谱的话，客户端是会拿到错误的返回数据的。它同DNS欺骗一样，是可以对客户端进行钓鱼攻击的。
如果这个翻译官口风不严的话，它可能会将它听到的敏感信息泄露给别人

413 Request Entity Too Large

客户端上传图片太大超过服务器限制时，服务器返回413错误。

414 Request-URI Too Long

客户端访问的URI太长，超出了服务器允许限制，服务器返回414错误。

202 Accepted

常用于异步请求。客户端发送请求到服务器，服务器立即返回一个202 Accepted表示已经成功接收到客户端的请求。
后面怎么处理由服务器自己决定，一般服务器会给客户端预留一个可以查询处理状态的接口，客户端可以选择轮训该接口来知道请求的处理进度和结果。

POST提交数据的方式

application/x-www-form-urlencoded

提交数据表单时经常使用，Body内部存放的是转码后的键值对。

POST http://xyz.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
a=1&b=2&c=3&c=4

application/json

提交结构化表单时使用，Body内部存放的是JSON字符串。ElasticSearch的查询协议使用的是这种方式。

POST http://xyz.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"a": 1, "b": 2, "c": [3, 4]}

multipart/form-data

上传文件时经常使用。这种格式比较复杂，它是为了支持多文件上传混合表单数据而设计的一种特殊的格式。

<form action="http://example.com/upload" method="post" enctype="multipart/form-data">
  <p><input type="text" name="key1" value="value1">
  <p><input type="text" name="key2" value="value2">
  <p><input type="file" name="file1">
  <p><input type="file" name="file2">
  <p><button type="submit">Submit</button>
</form>

用户填充了表单设置了待上传的文件，点击Submit，传输数据大致如下

POST /upload HTTP/1.1
Content-Length:xxxxx
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryKOThiwE6HubGib7j
Host:example.com
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="key1"
value1
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="key2"
value2
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="file1"; filename="file1name.png"
Content-Type: image/png
file1 content here
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="file2"; filename="file2name.jpeg"
Content-Type: image/jpeg
file2 content here
------WebKitFormBoundaryKOThiwE6HubGib7j--

Cookie

浏览器请求的Cookie中往往会携带敏感信息。服务器一般会将当前用户的会话ID存在cookie里，会话的具体内容存在服务器端，会话的内容很敏感。

浏览器请求时会携带Cookie信息，服务器根据Cookie信息中的会话ID找到对应的会话内容。会话内容里可能存储了用户的权限信息，拿到这部分权限信息后就可能随意控制修改用户的数据。

因为HTTP协议的不安全性，请求数据包很容易被窃听，Cookie中的会话信息很容易被盗。解决方案之一就是在会话中记录用户的终端信息和IP地址信息，如果这些信息突然发生改变，需要强制用户重新认证。

不过高级的黑客是可以伪造出和用户真实请求一摸一样的数据包的。最彻底的解决方案还是采用HTTPS协议。

普通的Cookie信息可以通过Javascript脚本获取到。如果黑客通过某种方式在网页中植入不安全的脚本，将用户的Cookie拿到然后发送到远程的第三方服务器中，那么Cookie中的信息就被泄露了。

Cookie的两个重要属性

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

被标记为Secure的Cookie信息在HTTP请求中不会被传送，它只会在HTTPS请求中传送，避免数据被泄露。

被标记为HttpOnly的Cookie信息是无法通过Javascript API获取到的，它只会在请求中传送。这样可以避免黑客通过网页脚本方式窃取Cookie中的敏感信息。

Cookie(甜点)如此好吃，黑客们总想通过Cookie做各种文章。

CSRF(Cross-Site Request Forgery)

CSRF跨站请求伪造有很多别名，比如One-Click Attack(一键攻击)，比如Session Riding(搭便车攻击)

假设在在一个社区博客网站中，删除个人的文章只需要一个URL就可以，Cookie中的会话权限信息会自动附加到请求上。

# 123456为文章的ID
http://example.com/blog/123456/delete

那么当别人伪造了一个上面的链接地址诱惑你去点击，比如通过站内信件、私聊、博客评论、图片链接或者在别的什么网站上随机制造的一个链接。你不经意点了一下，就丢了你的文章。所以它被称为一键攻击。因为这是借用了你当前登陆的会话信息来搞事，所以也被称为搭便车攻击。

如果在一个金融系统中，转账要是也可以通过一个简单的URL进行的话，那这种危险就非同小可。

这就要求修改性的操作务必不得使用简单的GET请求进行处理。但是即使这种情况下你改成了POST请求，黑客依然有办法伪造请求，那就是通过iframe。

黑客在别的什么网站上伪造了一个POST表单，诱惑你去submit。如果只是普通的内嵌进HTML网页的表单，用户提交时会出现跨域问题。因为当前网站的域名和表单提交的目标域名不一致。但是如果通过iframe来内嵌表单，则可以绕过跨域的问题，而用户却完全没有任何觉察。

为了防范CSRF攻击，聪明的网站的POST表单里都会带上CSRF_TOKEN这个隐藏字段。CSRF_TOKEN是根据用户的会话信息生成的。当表单提交时，会将token和用户的会话信息做比对。如果匹配就是有效的提交请求。

<form method="POST" action="/blog/delete">
<label for="blog_id">博客ID</label>
<input type="text" name="blog_id" value="12345">
<input type="hidden" name="csrf_token" value="xxxxxxxxxxxx">
</form>

黑客必须拿到CSRF_TOKEN才可以借用用户的会话信息实施CSRF攻击，但是CSRF_TOKEN又必须由用户的会话信息才可以生成。黑客没有用户的会话信息，从而无法实施CSRF攻击。

XSS(Cross Site Scripting)

如果黑客可以在你的网页中植入任意Javascript脚本，那他就可以随意鱼肉你的账户。通过Javascript可以获取Cookie的信息，可以借用你的会话去调用一些隐秘的API，而这一些行为都是在偷偷的进行，你根本完全不知道。

<div>
# 用户内容Start
<script>send_to_hacker(document.cookie)</script>
# 用户内容END
</div>

这类攻击在一些UGC网站中非常常见，常见的博客类网站就是UGC网站，用户可以通过编辑内容来生成网页。

黑客也是用户。他可以编辑一段Javascript脚本作为内容提交上去。如果服务器没有做好防范，这段脚本就会在生成的网页中运行起来。当其它用户在登陆的状态下来浏览这个网页的时候，就悲剧了。

防范XSS一般是通过对输出的内容进行内容替换做到的。在HTML页面中不同的位置会有不同的内容替换规则。
比较常见的是使用HTML entity编码将HTML标签之间的内容中的一些特殊的字符进行转码。

<div>
# safe now
&lt;script&gt;send_to_hacker(document.cookie)&lt;/script&gt;
</div>

还有些UGC内容在HTML标签的属性中、Javascript的变量中、URL、css代码中，他们转码的规则并不一样，具体方法可以去Google相关文档。

跨域

跨域是个很头痛的问题。

当你有多个后端服务，但是只有一个前端的时候，你想做前后端分离，就会遇到跨域问题。你发现你的前端js调用后端服务时控制台告诉你不ok。然后只好把这些服务都挂在了同一个nginx域名下面，通过url前缀区分。

这时候你会想，跨域太TM讨厌了。既然跨域这么讨厌，那为什么浏览器非要限制跨域呢？

还是安全原因。

让我们回到上文的搭便车攻击(Session Riding)，也就是骑着别人的会话来搞事情。

假设现在你的浏览器开了一个站点A，登陆了进去，于是cookie便记录了会话id。
然后你又不小心开了另一个站点B，这个站点页面一打开就开始执行一些恶意代码。这些代码的逻辑是调用站点A的API来获取站点A的数据，因为可以骑着(Ride)站点A的会话cookie。而这些数据正好是用户私密性的。于是用户在站点A上的私有信息就被站点B上的代码窃走了。这就是跨域的风险。

但是有时候我们又希望共享数据给不同的站点，该怎么办呢？

答案是JSONP & CORS

JSONP(JSON Padding)

JSONP通过HTML的script标记实现了跨域共享数据的方式。JSON通过在网页里定义一个回调方法，然后在页面上插入一个动态script标签，指向目标调用地址。服务器会返回一段javascript代码，一般是some_callback(data)这种形式的回调。该段代码会在浏览器里自动执行，于是网页就得到了跨域服务器返回的数据。

<script>
function some_callback(data) {
    console.log(data)
}
</script>
<script src="http://example.com/someapi?callback=some_callback"></script>

因为JSONP是不携带cookie信息的，所以能有效避免搭便车攻击。JSONP是否可以获取到数据还需要服务器对这种调用提供显示支持，服务器必须将数据以javascript代码的形式返回才可以传递给浏览器。

CORS(Cross-Origin Resource Sharing)

JSONP的不足在于它只能发送GET请求，并且不能携带cookie。而CORS则可以发送任意类型的请求，可以选择性携带cookie。

CORS是通过Ajax发送的跨域请求技术。CORS的请求分为两种，一种是简单请求，一种是复杂请求。简单请求就是头部很少很简单的GET/HEAD/POST请求。复杂请求就是非简单请求。

浏览器发现Ajax的请求是跨域的，就会在请求头添加一个Origin参数，指明当前请求的发起站点来源。服务器根据Origin参数来决定是否授权。

如果是简单请求，Ajax直接请求服务器。服务器会当成普通的请求直接返回内容，不同的是还会在响应头部添加几个重要的头部，其中最重要的头部是Access-Control-Allow-Origin: http://example.com。

浏览器如果在响应中没有读到这个头部，就会通知Ajax请求失败。虽然服务器返回了数据，浏览器也不让脚本读到数据，这就保证了跨域的安全。服务器就是通过请求的Origin参数来决定要不要响应Access-Control-Allow-Origin头部来决定是否允许指定网站的跨域请求。

如果是复杂请求，要走一个预检的流程。预检就是浏览器先向服务器发送一个Method为Options的请求，如果服务器允许跨域请求，浏览器再发起这个Ajax请求。所以CORS的复杂请求会比简单请求额外耗费一个TTL的时间。

CORS的细节请参见大神阮一峰的博文《跨域资源共享CORS详解》

from:https://mp.weixin.qq.com/s/aekcsgLG6jZw3LeF3R9ssQ

视频编码与封装综述

三月 20, 2018计算理论编码, 视频dotte

随着多媒体技术和网络通信技术的快速发展，视频多媒体应用已经覆盖了大众生活的方方面面。尤其是近年来高清和超高清视频应用越来越广泛，相比于标清视频，高清视频分辨率更高、画面更清晰，其数据量也更大。如果未经压缩，这些视频将很难应用于实际的存储和传输。这里我们就要提到视频应用中的一项关键技术——视频压缩编码技术！

视频压缩编码技术可以有效地去除视频数据中冗余信息，实现视频数据在互联网中快速传输和离线存储

视频技术起源于第二次工业革命，随着视频技术的发展，一系列的视频编码标准被研发被使用。

压缩标准的变迁

目前已有的视频压缩标准有很多种，包括国际标准化组织（International Organization for Standardization, ISO）/国际电工技术委员会（International Electrotechnical Commission, IEC）制定的MPEG-1、MPEG-2、MPEG-4标准，国际电信联盟电信标准化部门（International Telecommunication Union-Telecom, ITU-T）制定的H.261、H.263。

2003年3月，ITU-T和ISO/IEC 正式公布了H.264/MPEG-4 AVC视频压缩标准。H.264作为目前应用最为广泛的视频编码标准，在提高编码效率和灵活性方面取得了巨大成功，使得数字视频有效地应用在各种各样的网络类型和工程领域。为了在关键技术上不受国外牵制，同时也不用交大量的专利费用，中国也制定了AVS系列标准，可以提供与H.264/AVC相当的编码效率。

随着用户体验的升级，更高码率的视频也在被提供，比如超高清（3840 x 2160）。相对于标清视频，其分辨率更高，数据量也更多。在存储空间和网络带宽有限的情况下，现有的视频压缩技术已经不能满足现实的应用需求。为了解决高清及超高清视频急剧增长的数据率给网络传输和数据存储带来的冲击，ITU-T和ISO/IEC联合制定了具有更高的压缩效率的新一代视频压缩标准HEVC（High Efficiency Video Coding）。

HEVC简单介绍

HEVC：新一代视频压缩标准，以传统的混合视频编码为框架，并采用了更多的技术创新，包括灵活的块划分方式、更精细的帧内预测、新加入的Merge模式、Tile划分、自适应样点补偿等。

这些技术一方面使得HEVC编码性能比H.264/AVC提高了一倍，另一方面也将编码复杂度大大增加，不利于HEVC的应用和推广。

在这里着重说一下块划分方式——对编码性能提升最大。块划分包括编码单元（CU）、预测单元（PU）和变换单元（TU）。但是，递归的对每个编码单元进行率失真优化过程（RDO）来选择最优的模块划分的复杂度很高，其需要巨大的计算复杂度。因此降低HEVC编码复杂度的是视频行业人员所希望看到的。

图1 视频编码框图

新一代编码器对比

常见的封装格式有以下几种：· AVI(Audio Video Interleave):只能封装一条视频轨和音频轨，不能封装文字，没有任何控制功能，因而也就无法实现流媒体，其文件扩展名是.avi。

· WMV(Windows Media Video):具有数字版权保护功能，其文件扩展名是.wmv/.asf。

· MPEG(Moving Picture Experts Group):可以支持多个视频、音轨、字幕等，控制功能丰富，其文件扩展名是.mp4。

· Matroxska:提供非常好的交互功能，比MPEG更强大，其文件扩展名是.mkv。

· QuickTime File Farmat:由Apple开发，可存储内容丰富，支持视频、音频、图片、文字等，其文件扩展名是.mov。

· FLV(Flash Video):由Adobe Flash延伸而来的一种视频技术，主要用于网站。

· TS流（Transport Stream）：传输流，将具有共同时间基准或独立时间基准的一个或多个PES组合（复合）而成的单一数据流（用于数据传输）。目前TS流广泛应用于广播电视中，如机顶盒等。

总结

本文简单介绍了视频的编码与封装，其是视频通信中重要的一步，如果这一步出了问题，很容易导致视频无法被读取或无法播放的状态。下一节，我们将来说一下视频通信中的音视频处理技术。from:https://mp.weixin.qq.com/s/9hClcofo8HEI8QqDpef12Q

想要做”架构师“，一定要会画设计图

三月 9, 2018架构架构师, 设计图dotte

什么是系统架构师？

系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。

架构师在软件开发的整个过程中起着很重要的作用。

如何才能成为系统架构师？

1. 首先必须具有丰富的软件设计与开发经验，这有助于理解并解释所进行的设计是如何映射到实现中去。

2. 其次要具有领导能力与团队协作技能，软件架构师必须是一个得到承认的技术领导，能在关键时候对技术的选择作出及时、有效的决定。

3. 第三是具有很强的沟通能力，其实这一点好像什么角色都最好具备，软件架构师需要与各路人马经常打交道，客户、市场人员、开发人员、测试人员、项目经理、网络管理员、数据库工程师等等，而且在很多角色之间还要起沟通者的作用。

而设计图，它不是简单的供你欣赏，他其实是架构师，产品经理，开发工程师，测试工程师等各种角色之间进行沟通的语言，沟通的一个桥梁，让整个团队更能有效的协调工作。

设计图不单单是架构师要掌握的，在一个产品的开发过程中，任何一个环节，任何一个角色都可以通过掌握不同的设计图来完成沟通的。

流程图

流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）产品经理做需求前一定要先把这些逻辑关系理清楚，如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。

图就是将你头脑中的逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，因为是图，你可以像你的版本迭代一样，当你的逻辑需要修改的时候拿出来迭代一下，同时因为有图，你还可以更好的给项目成员进行宣讲。

产品中设计的流程图主要有三种，业务流程图、任务流程图、页面流程图，下面我们来一一介绍。

业务流程图

业务流程图又称为泳道图，就是描述那些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：

1. 涉及到哪些主体？

2. 每个主体都有哪些任务？

3. 各个主体之间怎么联系的？一般涉及到多个主体，每个主体之间有联系。

任务流程图

泳道图一般是从战略上分析整个业务流程，让你对公司所做的业务有个大概的了解，而任务流程图就是在你的产品操作上，用户通过什么样的操作来完成它的目标，比如你去银行ATM机器上取钱，你是如何一步步操作把钱取出来的。

页面流程图

如果说业务流程图帮助你梳理战略，任务流程图帮助你梳理用户操作行为（主要给程序员看）、页面跳转流程在帮助你梳理各个页面之间的跳转关系（主要给UI和前端程序员看）这是一个逐步从整体到局部，从后端到前端的过程。

所有的产品都是由页面组成的，不论是APP、PC、H5都是由一个个页面组成的，页面流程图描述完成一个任务需要经过哪些步骤，你在画图的时候只需要清晰的表现出用户点击页面的什么地方，然后跳转到那个页面。主要由页面、行动点、连接线组成。

UI设计图标注

对于APP的页面，UI设计师会给出UI设计标注图，这样APP客户端开发人员，直接按照标注图进行页面的开发了。

产品设计完成后，架构师需要对产品进行软件的架构设计。包括技术的选型，模块的划分，开发人员的任务分配，工作量的评估等等…..

系统架构设计图

构架将在一次又一次迭代中不断演化、改进、精炼。

序列图

架构师一般在做详细设计的时候，会把程序模块之间的每一步调用过程很详细的画出来，这样开发人员拿到设计文档，就能直接开发。

类图

设计图有很多种，还包括用例图，状态图，活动图…… 不再一一介绍。画什么样的设计图，不是绝对的，不同公司，不同项目，需要画的设计图也是不同的，有些项目需要画原型图，有些项目只是对外提供服务，没有页面也就不需要画原型图。另外还要根据项目的工期，预算等等因素考虑。如果一个项目的工期也就一个月甚至更短，那基本上就是怎么简单怎么快就怎么做。

画图工具

‘工欲善其事,必先利其器’，下面就为大家介绍几款常用设计图绘制工具。以下软件都可以在微信公众号，回复“设计”，获取破解版本。

Visio

是微软推出的一款流程图绘制工具，它有很多组件库，可以方便快捷的完成流程图、泳道图、结构图的绘制，但是不支持mac电脑。

OmniGraffle

Mac下没有Visio很多人就用这个，这个一般流程图都能绘制，但是效率感觉没有Visio高，优点就是画出来的图形比较美，同时支持外部插件，缺点就是没有比较好的泳道流程图插件，画起泳道图来不是太方便，但也可以画，可以自己组装泳道。

另外一个缺点是收费的，只能免费试用15天，不过我已经为大家准备好了一个最新的破解版本。

ProcessOn

是一款网页版的在线作图工具，优点是无需下载安装、破解这些破事，同时支持在线协作，可以多人同时对一个文件协作编辑，而且上手比较容易，它提供很多流程图模版，可以方便的画出流程图、思维导图、原型图、UML图，缺点就是在绘制泳道图需要增加泳道的时候，只能在最后一列加入，不能在中间加入这一点有点麻烦，还有要吐槽的就是由于是在线的，有时候导出图片，导出来的并不太好，流程图画的大的时候也无法截图。

在线地址：https://www.processon.com

Axure RP

这是一款产品经理经常用来画原型的工具，它可以在页面里定义各种按钮点击事件，进行页面的跳转，模拟提交的过程，所以非常方便使用。画人物流程图的时候也可以用，但是要画泳道图、UML图的时候，没有对应的模版，需要自己画，效率不高，如果你觉得画原型，制作文档都在Axure里，不想来回切换软件的画，可以在里面自己制作一个组件，下次直接调用。

Axure RP是可以画出这样效果的原型图

PxCook

一款还不错的标注工具.

优点：

1. 成熟：跨平台——支持Windows和Mac

2. 成熟2：支持PS和Sketch。

3. 交互特别智能，也方便，一拖一放就标注完了。

4. 相当需要说的一点：对于PSD文件或者Sketch进行了修改之后，PxCook里的标注会自动进行更新，免除了手动操作的过程。这是后面很多软件没有的。

5. 支持移动设备的多单位切换。

缺点：

1. 不能支持多个文件同时进行标注。

2. 对于图层样式等信息，不能进行详细查看。

iThoughtsX

一款优秀的思维导图工具

OmniPlan

最NB的项目管理流程软件，OmniPlan旨在帮助您可视化，维护和简化您的项目。分解任务，优化所需的资源，控制成本，并监控您的整个计划，都一目了然。协作与您的同事和分享每一个细节，更新日历与你的天关，或混搭。接受和拒绝一次过改变一个接一个或所有。

OmniPlan提供了像甘特图，时间表，摘要，里程碑和关键路径的功能突出显示，让您管理您的所有活动。从自定义的视图来快速输入数据， OmniPlan帮助您管理，因为你需要他们，简单或复杂的项目是 – 不需要复杂。

以上软件都可以在微信公众号，回复“设计”，获取破解版本。

Android+TensorFlow+CNN+MNIST 手写数字识别实现

二月 11, 2018ML&DLCNN, DeepLearning, TensorFlowdotte

Catalogue

Overview

本文系“SkySeraph AI 实践到理论系列”第一篇，咱以AI界的HelloWord 经典MNIST数据集为基础，在Android平台，基于TensorFlow，实现CNN的手写数字识别。
Code~

Practice

Environment

TensorFlow： 1.2.0
Python： 3.6
Python IDE： PyCharm 2017.2
Android IDE： Android Studio 3.0

Train & Evaluate（Python+TensorFlow）

训练和评估部分主要目的是生成用于测试用的pb文件，其保存了利用TensorFlow python API构建训练后的网络拓扑结构和参数信息，实现方式有很多种，除了cnn外还可以使用rnn，fcnn等。
其中基于cnn的函数也有两套，分别为tf.layers.conv2d和tf.nn.conv2d， tf.layers.conv2d使用tf.nn.conv2d作为后端处理，参数上filters是整数，filter是4维张量。原型如下：
convolutional.py文件
def conv2d(inputs, filters, kernel_size, strides=(1, 1), padding=’valid’, data_format=’channels_last’,
dilation_rate=(1, 1), activation=None, use_bias=True, kernel_initializer=None,
bias_initializer=init_ops.zeros_initializer(), kernel_regularizer=None, bias_regularizer=None,
activity_regularizer=None, kernel_constraint=None, bias_constraint=None, trainable=True, name=None,
reuse=None)

gen_nn_ops.py 文件

def conv2d(input, filter, strides, padding, use_cudnn_on_gpu=True, data_format="NHWC", name=None)

官方Demo实例中使用的是layers module，结构如下：

Convolutional Layer #1：32个5×5的filter，使用ReLU激活函数
Pooling Layer #1：2×2的filter做max pooling，步长为2
Convolutional Layer #2：64个5×5的filter，使用ReLU激活函数
Pooling Layer #2：2×2的filter做max pooling，步长为2
Dense Layer #1：1024个神经元，使用ReLU激活函数，dropout率0.4 (为了避免过拟合，在训练的时候，40%的神经元会被随机去掉)
Dense Layer #2 (Logits Layer)：10个神经元，每个神经元对应一个类别（0-9）

核心代码在cnn_model_fn(features, labels, mode)函数中，完成卷积结构的完整定义，核心代码如下.

也可以采用传统的tf.nn.conv2d函数, 核心代码如下。

Test（Android+TensorFlow）

核心是使用API接口： TensorFlowInferenceInterface.java
配置gradle 或者自编译TensorFlow源码导入jar和so
compile ‘org.tensorflow:tensorflow-android:1.2.0’
导入pb文件.pb文件放assets目录，然后读取
String actualFilename = labelFilename.split(“file:///android_asset/“)[1];
Log.i(TAG, “Reading labels from: “ + actualFilename);
BufferedReader br = null;
br = new BufferedReader(new InputStreamReader(assetManager.open(actualFilename)));
String line;
while ((line = br.readLine()) != null) {
c.labels.add(line);
}
br.close();
TensorFlow接口使用
最终效果：

Theory

MNIST

MNIST，最经典的机器学习模型之一，包含0~9的数字，28*28大小的单色灰度手写数字图片数据库，其中共60,000 training examples和10,000 test examples。
文件目录如下，主要包括4个二进制文件，分别为训练和测试图片及Label。

如下为训练图片的二进制结构，在真实数据前（pixel），有部分描述字段（魔数，图片个数，图片行数和列数），真实数据的存储采用大端规则。
（大端规则，就是数据的高字节保存在低内存地址中，低字节保存在高内存地址中）

在具体实验使用，需要提取真实数据，可采用专门用于处理字节的库struct中的unpack_from方法，核心方法如下：
struct.unpack_from(self._fourBytes2, buf, index)

MNIST作为AI的Hello World入门实例数据，TensorFlow封装对其封装好了函数，可直接使用
mnist = input_data.read_data_sets(‘MNIST’, one_hot=True)

CNN（Convolutional Neural Network）

CNN Keys

CNN，Convolutional Neural Network，中文全称卷积神经网络，即所谓的卷积网（ConvNets）。
卷积（Convolution）可谓是现代深度学习中最最重要的概念了，它是一种数学运算，读者可以从下面链接[23]中卷积相关数学机理，包括分别从傅里叶变换和狄拉克δ函数中推到卷积定义，我们可以从字面上宏观粗鲁的理解成将因子翻转相乘卷起来。
卷积动画。演示如下图[26]，更多动画演示可参考[27]
神经网络。一个由大量神经元（neurons）组成的系统，如下图所示[21]

其中x表示输入向量，w为权重，b为偏值bias，f为激活函数。
Activation Function 激活函数：常用的非线性激活函数有Sigmoid、tanh、ReLU等等，公式如下如所示。
- Sigmoid缺点
  - 函数饱和使梯度消失（神经元在值为 0 或 1 的时候接近饱和，这些区域，梯度几乎为 0）
  - sigmoid 函数不是关于原点中心对称的（无0中心化）
- tanh：存在饱和问题，但它的输出是零中心的，因此实际中 tanh 比 sigmoid 更受欢迎。
- ReLU
  - 优点1：ReLU 对于 SGD 的收敛有巨大的加速作用
  - 优点2：只需要一个阈值就可以得到激活值，而不用去算一大堆复杂的（指数）运算
  - 缺点：需要合理设置学习率（learning rate），防止训练时dead，还可以使用Leaky ReLU/PReLU/Maxout等代替
Pooling池化。一般分为平均池化mean pooling和最大池化max pooling，如下图所示[21]为max pooling，除此之外，还有重叠池化（OverlappingPooling）[24]，空金字塔池化（Spatial Pyramid Pooling）[25]
- 平均池化：计算图像区域的平均值作为该区域池化后的值。
- 最大池化：选图像区域的最大值作为该区域池化后的值。

CNN Architecture

三层神经网络。分别为输入层（Input layer）,输出层（Output layer）,隐藏层（Hidden layer），如下图所示[21]
CNN层级结构。斯坦福cs231n中阐述了一种[INPUT-CONV-RELU-POOL-FC]，如下图所示[21]，分别为输入层，卷积层，激励层，池化层，全连接层。
CNN通用架构分为如下三层结构：
- Convolutional layers 卷积层
- Pooling layers 汇聚层
- Dense (fully connected) layers 全连接层
动画演示。参考[22]。

Regression + Softmax

机器学习有监督学习（supervised learning）中两大算法分别是分类算法和回归算法，分类算法用于离散型分布预测，回归算法用于连续型分布预测。
回归的目的就是建立一个回归方程用来预测目标值，回归的求解就是求这个回归方程的回归系数。
其中回归（Regression）算法包括Linear Regression，Logistic Regression等， Softmax Regression是其中一种用于解决多分类（multi-class classification）问题的Logistic回归算法的推广，经典实例就是在MNIST手写数字分类上的应用。

Linear Regression

Linear Regression是机器学习中最基础的模型，其目标是用预测结果尽可能地拟合目标label

多元线性回归模型定义
多元线性回归求解
Mean Square Error (MSE)
- Gradient Descent（梯度下降法）
- Normal Equation（普通最小二乘法）
- 局部加权线性回归（LocallyWeightedLinearRegression, LWLR )：针对线性回归中模型欠拟合现象，在估计中引入一些偏差以便降低预测的均方误差。
- 岭回归（ridge regression)和缩减方法
选择： Normal Equation相比Gradient Descent，计算量大（需计算X的转置与逆矩阵），只适用于特征个数小于100000时使用；当特征数量大于100000时使用梯度法。当X不可逆时可替代方法为岭回归算法。LWLR方法增加了计算量，因为它对每个点做预测时都必须使用整个数据集，而不是计算出回归系数得到回归方程后代入计算即可，一般不选择。
调优：平衡预测偏差和模型方差（高偏差就是欠拟合，高方差就是过拟合）
- 获取更多的训练样本 – 解决高方差
- 尝试使用更少的特征的集合 – 解决高方差
- 尝试获得其他特征 – 解决高偏差
- 尝试添加多项组合特征 – 解决高偏差
- 尝试减小 λ – 解决高偏差
- 尝试增加 λ -解决高方差

Softmax Regression

Softmax Regression估值函数（hypothesis）
Softmax Regression代价函数（cost function）
理解：
Softmax Regression & Logistic Regression：
- 多分类 & 二分类。Logistic Regression为K=2时的Softmax Regression
- 针对K类问题，当类别之间互斥时可采用Softmax Regression，当非斥时，可采用K个独立的Logistic Regression
总结： Softmax Regression适用于类别数量大于2的分类，本例中用于判断每张图属于每个数字的概率。

References & Recommends

MNIST

Softmax

CNN

TensorFlow+CNN / TensorFlow+Android

By SkySeraph-2018

SkySeraph cnBlogs
SkySeraph CSDN

本文首发于skyseraph.com：“Android+TensorFlow+CNN+MNIST 手写数字识别实现”

一、各系统组件选型

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

2、DNS

3、LB(负载均衡)

4、CDN

5、RPC框架

6、名字发现/服务发现

7、关系数据库

8、NoSQL

9、消息中间件

10 、代 码管理

11、持续集成

12、日志系统

13、监控系统

14、配置系统

15、发布系统/部署系统

16、跳板机

17、机器管理

二、创业公司的选择

1、选择合适的语言

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

3、制定流程和规范

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

5、选择过程中需要思考的问题

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

参考资料

如果不用HTTPS，HTTP协议如何安全的传输密码信息？

文件路径攻击

DNS欺骗

谨慎使用外部的HTTP代理

413 Request Entity Too Large

414 Request-URI Too Long

202 Accepted

POST提交数据的方式

Cookie

Cookie的两个重要属性

CSRF(Cross-Site Request Forgery)

XSS(Cross Site Scripting)

跨域

JSONP(JSON Padding)

CORS(Cross-Origin Resource Sharing)

Overview

Practice

Environment

Train & Evaluate（Python+TensorFlow）

Test（Android+TensorFlow）

Theory

MNIST

CNN（Convolutional Neural Network）

CNN Keys

CNN Architecture

Regression + Softmax

Linear Regression

Softmax Regression

References & Recommends

10 、代码管理