前言

三年前写过一系列文章 初创公司的技术选型^[1]，介绍我们初期的技术选型。经过了三年，业务发生了变化，我们的技术架构也发生了变化。 技术需要不断迭代，技术的发展是为了更好的支撑业务，而不是为改而改，为新而新，为用而用。 所以我会更多的从业务视角来审视我们的技术架构。

我们的业务都是部署在云平台上，做为一家初创企业，云确确实实提升了我们的效率，让我们更多专注于自己的业务开发。 当然不可避免的，我们在上云和使用云的过程，也遇到了不少问题，踩了不少坑。我也希望在这一系列的文章里为大家提供实战经验，踩过的坑，以及云产品的一些另类玩法。

备注说明： 本系列文章主要介绍了业务架构的云原生实现思路，虽然我们同时使用了多个云，但是为了叙述便利，云产品主要以阿里云的产品做为示例说明，使用其它云的童鞋亦可寻找同类替代产品进行实现。

业务背景

既然是业务视角，就需要业务开始说起。 我们是深圳的一家创业公司， 提供一站式的会员方案设计，产品研发，营销活动策划，权益供应链整合和管理，用户售后等服务，助力合作伙伴快速高效发展付费会员业务。 目前累计服务超过 50 家企业， 超过 300 万付费会员。简而言之，我们是一家输出付费会员体系建设能力，帮助企业做增长的商业型 SaaS 公司。

我们的业务属性，也决定了我们在业务系统设计的目标。 我们的业务系统的设计的目标总结下来是“四高”： 高效率， 高可用， 高并发， 高扩展。

谈谈我对这几个目标的理解。

高效率： 指的是系统的部署，升级，接入， 维护都是高效的，创业公司的人不像大公司能招来那么多人，所以必须保证提高每个人的人效，让大家把更多的精力投入到业务设计和开发上。

高可用： 指的是系统要稳定，不能动不动就出问题，我们服务的是 B 端客户，B 端客户对可用性的要求是比较高的，我们目前设定的 SLA 是 99.9%，即全年业务不可用的累计时间不超过 8.76 个小时。

高并发： 指的是系统能够承受比较高的并发量，我们的业务的终端使用者是消费者，伴随着营销活动推广，访问量也会存在突增的情况。 所以整个系统从前端到后端到数据库都要能支撑比较高的并发。

高扩展： 指的是系统能够水平扩展，我们目前服务的是百万级付费用户，但是未来随着业务的增长，用户量有可能达到千万级，甚至亿级。 这时候要求我们的系统能够水平扩展，可以简单的扩容不断增加整个系统的承载能力。

业务架构

先放我们的整体的业务架构图。

从上往下看 -->

一： 我们的业务服务对象是 B 端客户， C 端用户， S 端供应链， 还有我们内部的运营人员和客服人员等

二：对外服务的形态有 SDK， H5， 小程序和 App，所有这些都是通过统一的 API 网关接入后端服务， API 网关起到授权， 鉴权，限流，审计等等作用。

三：往下是具体的业务模块， 整个业务主要分成几大部分： 商品管理， 订单管理， 会员管理， 运营支撑， 支付信息管理，酒店信息管理等。这些业务模块可以以微服务的方式部署

四：底层我们用了公有云和容器平台。 我们的应用都做了容器化，并运行在 kubernetes 上面调度。公有云和公有云上的容器平台，不但为我们的业务提供了底层的计算能力，也为我们提供了底层的稳定性保障。

从左往右看 -->

最左边是配置中心，安全中心和日志平台，分别管理我们应用的配置， 保障业务平台和底层架构的安全，采集业务日志方便审计，分析和定位。

最右边是统一发布平台和监控平台。 统一发布平台负责应用的发布，即 CI/CD。 监控平台负责底层服务器，网络，容器，容器平台以及业务应用等组件的全方位监控。

<未完待续...>

参考资料

[1]

初创公司的技术选型文章合集: http://mp.weixin.qq.com/mp/homepage?__biz=MzA4ODEwODcwMA==&hid=1&sn=a02d2bf9a9759522162caf585859e2fb&scene=18#wechat_redirect