本文内容源自「声网开发者创业讲堂第二期」的演讲分享，分享讲师为七牛云技术副总裁、go-zero 作者万俊峰 Kevin。大家可以点击 [创业讲堂第二期] (Agora开发者创业讲堂丨第2期：创业初期如何进行技术选型与架构设计？| 内含视频回放&资料)，观看视频回放及下载讲师 PPT。
01 后端技术选型
创业早期一般有两种形式，一种是标准的 startup 公司，另一种是公司内部孵化新的项目。在不同的场景下，技术选型存在差异。对于后端来说，在项目最初需要先预估业务的规模，该阶段需要解决语言选择、选择单体还是微服务、使用公有云还是私有云等一系列问题。
此时，建议优先关注业务价值的交付，尽量不要使技术过于复杂。尤其对于创业公司而言，此阶段对业务还没有一个清晰的预期，不应被技术的复杂度约束，应从单体的方式进行推进。
采用单体方式推进的整体流程如图 1 所示。首先，项目的一般标准是支持移动端和 PC 端，然后对 Service 进行访问。在创业初期，可以先简单地构建后端，用 Go 或者 Java 编写 Service 并挂载 DB，此时还不需要缓存。此外，还可以挂载 File Server 返回静态文件，这样，整个业务就可以运行了。此时项目已经可以支撑上千甚至上万的用户量。
■ 图 1
随着业务的发展，在此基础上对该流程进行补充设计时，可以在系统中添加 NGINX 进行简单的负载均衡，通过 NGINX 访问 Service，同时对 DB 进行扩展。对业务进行进一步扩展后，可以将 File Server 切换为云厂商的 OSS 功能，并在原有 DB 的基础上通过 Redis 来进行简单的缓存，该阶段就可以承载相对大体量的业务，此时在 NGINX 之前补充 DNS 进行轮询可以进一步扩展，框架如图 2 所示。
■ 图 2
单体所能承担的业务规模有限，随着业务量的进一步扩展，各单体组合逐渐扩展为微服务体系。微服务的整体流程如图 3 所示。
■ 图 3
1.1 单体的优缺点
单体的优缺点比较明显。具体来说，优点是开发简单、测试简单、部署简单、私有化部署容易；缺点是难以理解和扩展、小改动也得全量更新、小问题容易触发大故障、能够支撑的业务规模有限。
1.2 微服务的优点
微服务的优点是边界清晰的业务拆分，易开发、易理解、易维护，技术栈可相对独立，持续集成、持续部署，按需对服务进行治理，稳定性更容易保障。
1.3 微服务的缺点
微服务的缺点是增加了系统复杂度、数据拆分复杂度，难调试、难测试，跨服务修改麻烦，难部署。
1.4 如何选择
对于单体和微服务的选择，首要考虑的是业务。团队应该对业务有简单的预判，将技术与业务结合起来，而不能只聚焦于技术。比如考虑业务到底是 ToB 还是 ToC，如果体量可控，则可以选择单体；在体量较大的情况下，则选择微服务，保障高并发的稳定性。 然后要分析团队，如果团队成员有非常成熟的微服务经验，对整个技术体系理解得非常完备和通透，那么单体和微服务对团队而言没太大的区别。此外，对于创业公司，应该从简单入手，简化技术体系，同时，技术负责人还要预留一定的可能性。
02 后端技术体系
2.1 微服务系统全览
对于完整的大型项目来说，如何进行技术体系的选择，可以参考图 4，其中的组成部分在业务流程中不一定都需要，但应做基本的掌握。
■ 图4
在请求产生以后，可能要先经过 CDN，然后到达 WAF（外部防火墙），设置 WAF 是因为某些业务的安全性等级要求非常高。接下来经过 SLB，它是由云厂商提供的，可以用来进行负载均衡。之后需要通过 NGINX 做反向代理，这是很常见的情况。随后是一个或者多个 k8s 集群，它承载了整个业务的主体部分。
除了这个主体部分以外，周边还有一系列的技术来支撑整个系统，比如建立日志分析的系统告警平台以及大数据系统，因此需要通过 Kafka 到达 go-slash，然后用 ES 来进行日志的检索，在 DB 层则采用 MySQL、Mongo 以及 Redis （进行缓存）。另外，在接收到报警、监控后需要开发团队进行故障处理，此时，应该进入 GitLab，与 GitLab CI 结合，通过 Jenkins、workflow 等做 CI/CD 的相关工作，最后进入私有化镜像仓库。
2.2 微服务系统请求链路
对以上体系的周边进行简化，就可以得到微服务系统请求链路，如图 5 所示。在业务搭建的过程中，对于初创公司，建议结合自身的成本和技术掌握程度，尽可能使用行业内广泛适用的技术。
■ 图 5
2.3 全局视角看后端系统
接下来，我们将从全局视角分析后端系统，需要注意以下几点：
2.3.1 自建 or 公有云？
私有云的定制性和可控性较强，有利于安全和数据监管。但对于现在的业务系统，除非有特别强的安全需求以及敏感数据的监管需求等，建议优先选用公有云，因为它具备更高的可扩展性和可靠性，运维成本更低。
创业早期建议使用云中立的技术，因为在进行云切换时，面对某一个厂商所特有的技术，会导致产生进行更多的操作等问题，或者即使能够进行操作也没有太多的议价空间，因此应该避免使用强绑定的技术。此外，建议尽量选择多云，这样在遇到故障时就可以快速切换，对于降低创业公司的成本也有一定的帮助。
2.3.2 系统安全性、数据安全性
对于初创公司来说，数据安全性是非常重要的，应该保证整个系统是最小化的，并对数据进行备份。其中，数据备份要注意演练数据，对于我的团队来说，每个月必须把数据导出进行恢复，确保所有的备份数据能恢复业务。
2.3.3 负载均衡、反向代理、ingress
负载均衡可以直接购买使用，但要严格区分是外网还是内网的请求，在数据进入内网以后，建议不要再进行内外网切换。关于负载均衡可以使用公有云的 SLB，关于反向代理可以参考图 6，这是一个关于重定向故障的案例。对于 Ingress 而言，它可用于自动化配置，但是配置文件需要版本控制。
■ 图6
2.3.4 Kubernetes or ECS
在云原生时代，建议使用 Kubernetes，它能够将运维能力全承载到开发系统。Kubernetes 的本质是一个运维工具，它的优点包括自动调度、服务自我恢复、分发最终状态、负载均衡和水平伸缩、使资源得到更充分的利用，并且令系统更可靠。
2.3.5 数据库选型、设计和治理
不同的业务场景，需要用特定的解决方案，让数据跨机房可用。如果数据库的选型有误，会导致数据冗余，进而影响数据治理，而数据治理是非常重要的，后续的很多工作依赖于完善的数据拆分和治理。
2.3.6 需不需要缓存？如何选择缓存方案
在系统出现问题时需要进行缓存。对于缓存方案的选择可以考虑 Redis 缓存、进程缓存和缓存框架。
2.3.7 数据收集、数据分析
市场的反馈跟预想通常是有很大偏差的，此时需要数据来检验和验证。建议先考虑数据能产生什么价值，前期可以人工进行数据收集，随着时间的推进系统化。另外，在架构上要预留可能性。
2.3.8 监控报警
业务必须具备监控报警功能，通过这种方式强制所有的服务具有可观测性，这是比较重要的。监控报警的作用是发现问题、定位问题和解决问题，它由采集、存储、分析、报警和处理五部分组成。对于监控报警应该做到指标尽量较少，报警尽量精确，并且责任到人。
2.3.9 代码仓库是单仓 or 多仓
单仓的特点是每个服务独立 repo，代码量和复杂度都是可控的，并且边界清晰，代码权限容易控制。而多仓的特点是在代码规范、集成和部署、项目整体理解和重用方面具有优势。推荐用单仓的方式，这有助于技术交流以及技术规范等各方面的统一和落地。
2.3.10 持续集成
持续集成（CI）的方案可以选择 Gitlab + Jenkins 或者 Github。它的优点是代码规范检测、单元测试、集成测试、文档同步都可以集成到工具中，在 CI 中进行提交的时候，验证使用是否正确，如果不正确就可以拒绝，建议能自动化检测和解决的事情尽量通过自动化的方式来进行。
2.3.11 持续交付
持续交付（CD）可以在 CI 的基础上手动触发，自动发布到 test、staging 等，验证后可以手动发生产。
■ 图7
2.3.12 持续部署
在对系统的认知和理解掌控程度足够的情况下，可以在持续集成的基础上进行自动的持续部署，自动发布到不同的环境，进行逐步验证和灰度发布。
■ 图8
2.3.13 中间件设计
此外，随着业务的发展，应尽量通过中间件的方式来提供扩展的可能性，尽量不要把代码都揉到一起。
03 前端技术选型
对客户端的选型，尽量不要选择太偏门的技术。比如，如果对客户端有强烈的性能要求，最好用原生来编写，如果要求没有这么高，甚至可以用 Flutter 来编写。另外，建议尽可能把逻辑点放到中间层代码中，在 iOS 和安卓端两侧共享。
关于开发规范和效率建设，可以参考 go-zero 官网，基本上所有与服务开发相关的方方面面都集成在工具中，极大地提升了研发的效率。go-zero 代码仓地址： GitHub - zeromicro/go-zero: A cloud-native Go microservices framework with cli tool for productivity.
答疑环节
1、如何权衡可拓展性和实现难度，怎么防止过度设计和设计不足？
在初创阶段，如果业务足够简单，应尽可能以最短的时间实现一个 MVP 版本的业务设计，实现业务价值的交付，通常是设计不足的。比如，要求一个月之内能把公司期望的业务上线，那么我认为一般情况下不会设计过度，只会设计不足。此时，建议采用单体的方式。任何系统都是逐步增大体量的，设计不足很常见，业务设计永远是不足的，系统设计不足证明业务发展比较好。随着业务的发展，可以把系统进行迭代改进，这是相辅相成的，当发现系统出现问题时，进行及时修改、优化，重新调整设计即可。所以我认为对创业团队来说，最重要的就是快速实现业务价值的交付。
2、初创团队以什么标准招聘，如何带技术团队技术，如何制定规范？
以后端为例，在选型没有问题的情况下，如果采用 go-zero 构建社区，按照 go-zero 的标准进行操作，基本上都可以实现业务价值，因为路径是统一的。所以我认为基础选型和实现方式是非常重要的，这决定了未来的方向，我的团队实习生一个月就可以熟练地编写业务了。因此可以发现，只要选好工具，对人的要求就会下降。另外，我希望技术规范都嵌入工具中，制定规范是因人而异的，应该寻找合适的工具和方案，然后坚定地执行，遇到问题再做调整。注意，在推进规范的时候，最好通过工具强制执行。
