完善架构设计
常规架构设计参考
在初创阶段，一般用户规模不大，而且业务并不成熟，更多的精力需要放在功能开发上，一般不会有太多资源投入进行技术打磨。因此建议尽量使用通用且团队熟悉的技术。前面我们分析了SaaS特有的多租户架构设计，下面我们讨论一下其他常规的设计考量。
- 单体架构OR微服务架构：从我们的实践来看，微服务架构需要较强的基础工具链的支撑才能有效的发挥作用，如果本身还没有一套成熟的DevOps工具，或团队不具备相关的知识，强烈建议初期使用单体架构。一般考虑前后端分离+MVC框架就可以了。
- 本地部署OR公有云部署：初创团队强烈建议使用公有云部署，像缓存、消息队列、对象存储、日志服务等中间件，公有云都有成熟的PaaS产品可用，可以省去很多运维精力。
- 开发模式：可以选择一种熟悉的敏捷开发模式，比如Scrum或看板，再配合一个对应的项目管理系统。如果是单个团队，代码分支模型可以使用GitHub Flow的方式，后面团队多了再考虑Git Flow等方式。可以考虑使用公有云厂商的CI/CD工具，或者使用开源或Jekins自己搭一个，有工具支撑比较手撸要省不少事，也能避免出现低级问题。
- 可观测性：建议云厂商有的，尽量先用云厂商的，不满足需求的再找开源。一般规模小，使用云厂商成本更低，规模大了后再基于成本和需求考虑自建。日志的规范性规划在最初就就内置到开发框架和规范中，避免后面积重难返。
- 任务调度：可以使用熟悉的开源任务管理系统。如果初期需求不多的话，可以自己做一个简单的任务管理模块，使用Crontab运行。
- CDN：如果应用需要提供给C端访问，或者有较多的图片视频等内容，为提高用户体验可能需要使用CDN。
逻辑架构
基于前面的分析，我们来看一下目前阶段的逻辑架构：
- 接入层：考虑安全，入口接入一个WAF，一般云厂商都有提供；网关可以使用自己熟悉的网关或Nginx；如果有需求可以将静态资源放到CDN中，一般云厂商有提供结合对象存储使用的服务，没有需求可以考虑放到Nginx中。
- 应用层：使用单体架构，内部按模块进行划分，前期尽量抽象业务无关的公共模块，便于维护和演进，因与业务关联小，所以比较好界定范围。
- 基础设施层：主要是数据库、缓存、队列、对象存储，其他的根据自身的技术选型，可能还会有配置中心、Nosql数据库等。
- DevOps：工具和支持系统方面，有很多开源和商用的可以选择，建议选择熟悉的工具和产品。应用部署所在云厂商提供的可以优先考虑。
部署架构
初创阶段建议使用公有云部署，特别是没有太多运维人员的情况，公有云基础设施稳定性相对有保障。公有云初期成本也相对较低。下面我们基于公有云部署，考虑系统安全、可用、性能和扩展来设计一个部署架构。如果是基于IDC，部署情况也类似，主要是基础设施需要自己部署和维护。
- 接入层：主要通过WAF来接收流量，转发到内部网关/代理层，可以把静态文件放到里面。
- VPC：应用服务访问第三方时，为了方便IP白名单管理，可以使用代理ECS作为统一的出口。
- 云PaaS层：直接购买云厂商的服务，服务器和缓存使用主从的一般就够了，后期量大可以切换为分布式的。MQ、对象存储和日志服务一般不区分部署方式，按量和性能购买。
如果网关层没有逻辑需要处理，将静态资源都使用CDN处理，则部署可以演变为以下架构：
运行架构
最后我们来看简单看一下运行架构。模拟一个涉及到APP短信验证码登录的场景，来串一下运行架构如下：
-
获取验证码：会先校验手机号在系统中是否存在，这里采用的是将所有租户手机号保存到一个映射表中的设计。存在则发送验证码，并缓存用于校验。
如要考虑安全风险，避免大量无效手机号请求，导致缓存击穿。可以考虑系统初始化时对缓存进行预热，将所有手机缓存起来，访问时只请求缓存，不请求数据库。数据有变更时，需要同步更新缓存。
-
验证码登录：验证码校验通过后，如果手机号对应多个租户，需要用户选择一个租户。租户未确定时，可以先保存会话信息及可选租户，未选择租户而直接进行后续操作时，先弹出租户选择界面让用户选择，确定租户后才能进行后续操作。
-
业务操作：此处以MVC框架举例，先通过会话信息确定租户，再根据租户到多租户管理模块拿到租户库连接。后续所有的权限校验、业务处理都基于此连接访问租户库。
