借鉴：https://www.xugj520.cn/amp/SaaS_Architecture.html
SAAS成熟度模型分级
LEVEL1 定制开发
软硬件都由SAAS效劳商提供，软件的使用者只需要按时间、用户数、空间等逐步支付租赁使用费用即可
LEVEL2 可配置
通过不同的配置满足不同用户的需求，而不需要为每个用户停止特定定制，以降低定制开发的本钱。
LEVEL3 高性能的多租户架构
多租户：通过一定的战略来保证不同租户间的数据隔离，确保不同租户即能共享同一个应用的运行实例，又能为用户提供独立的应用体验和数据空间。实现方案有独立数据库、共享数据库独立数据架构、共享数据库共享数据架构。
高性能：满足多租户并发访问的性能挑战。
LEVEL4 可伸缩性的多租户架构
处置租户数量增加因集中式数据库带来的性能瓶颈。
SAAS实现阶段性成熟度推进
定制开发 --> 可配置 --> 多租户 --> 高性能 --> 可伸缩
方式一：逻辑分层可迁移架构(单体式)
采用最终以迁移至分布式SOA或微效劳架构为目的的分层形式，相当于本地SOA（逻辑分层形式是基于SOA思想， 物理分层形式还是单体）：
架构特征:
界面层可以与整套应用程序分别也可以不分别；
所有的业务逻辑根本都存在于一套应用程序中，应用效劳也存在于同一套应用程序中；
可以使用一个或多个数据源，但多个数据源可以给所有业务逻辑层和应用效劳层使用；
表示层可以调用应用效劳层，也可以调用业务逻辑层；
效劳在应用程序内部互相调用。
架构优点:
所有业务逻辑在同一套应用程序中，所以不用考虑调用链治理、不用过多的考虑网络通讯，也不用考虑分布式一致性事务，所以与之关联的中间件都不是必需的。
架构形式简单，所以对人员技能的要求比较低。
一个或多个数据源，但是由于在同一套程序中，所以事务比较好处置。
中间件比较少，最根底的中间件就是一个ES用于全文检索，一个MQ用于解耦和多播任务。
所有的业务逻辑在同一套应用程序中，便于单元测试和集成测试；
部署简单，一台效劳器一个应用程序，使用负载平衡应对高并发；
由于业务逻辑都在同一个应用程序中，效劳治理可以集中做；
使用的开发人员较少；
可以实现显示层（即表示层和界面层可合并-传统的MVC，主要针对WEB应用）；
传统的SOA不允许暴露业务逻辑，只允许通过效劳层暴露效劳，这个架构允许暴露部分业务逻辑可以获得一些细粒度的效劳，降低开发难度。
架构缺点:
子系统不具备隔离性，一个子系统的解体有可能会导致其他子系统的解体，只能依靠应用程序中的效劳治理手腕，或在负载平衡层治理单个接口。 或采用路由分发的形式，每个部署的应用程序包含了完好的代码，但是因为路由分发的原因，该部署只提供了部分接口效劳。
系统的水平扩展不够灵敏，只要整体的水平应用程序复制的手腕，所以不适宜超大的应用系统。
不适宜需要分库的系统。
前端UI组件化依赖于前端的分别实现，或依赖于共同的H5页面。
所有业务领域层都必需面向对象设计编程。
代码增多容易混乱。
应用程序会很庞大。
成熟度模型的满足：
定制开发：满足度高
可配置：满足度中，通常通过配置+AOP切面编程实现
多租户：满足度低，通常只适宜共享数据库共享数据模型形式
高性能：满足度低，调优手腕有限，只能通过多实例负载平衡、查询优化、编程优化、缓存配置、路由分发的形式满足。
伸缩性：满足度低，多数都使用同一个数据库，同一种缓存战略，相同的NOSQL。
技术选型建议：
PHP > JAVA > GOLANG
单线程同步编程模型下PHP与JAVA的开发时间本钱几乎一致，多线程异步方案JAVA时间本钱要高一些，因为都需要DDD领域驱动设计，单线程同步编程模型实现时间不会有多少潮剧。多线程异步模型JAVA要处置更多的锁与内存， 这种架构PHP不适宜使用异步多线程编程模型。
人力本钱PHP低于JAVA，部署复杂度PHP低于JAVA，可复用可伸缩性JAVA高于PHP，项目可测试水平JAVA高于PHP。
技术方案中可能存在的不确定性：
架构师是否能按设计目的完成建模与分层分配；
开发组成员的素质是否能支撑领域驱动设计和单元测试；
总结说明：
简单易懂，开发快，人力本钱低。满足业务需求，且可迁移。但是，调优手腕有限，在系统的复杂度上（并发性应该足以支撑）升到一定水平后，需要更换到分布式SOA以及微效劳（通常在A B轮融资后）。
方式二：SOA架构(分布式)
架构特征：
松懈耦合，方案一仅提供了逻辑层面的松懈耦合，SOA在此根底之上还提供了物理层面的松懈耦合。
暴露API，企业外部也可以调用，方案一同样提供该特性，但是方案一的暴露API的方式比较统一死板，SOA可以根据需要对不同效劳使用不同的API暴露方案。
可重用的效劳和可重组效劳（方案一仅在逻辑层面重用和重组，物理层面欠缺）；
规范化的效劳接口；
准确定义的效劳契约；
架构优点：
有根本的独立性和平台中性，每个效劳都可以与平台和语言无关，这是方案一不具备的。
反复使用性和效劳的独立性，方案一也具备反复使用性，但是其中的效劳会于应用框架产生耦合，不具备独立性。
扩展性，方案一也具备可扩展性，但其扩展性会受到平台、语言以及应用框架的限制。
共享的业务效劳，方案一同样具备。
可定制业务流程，这通常在企业商务效劳中很有用；
6.有版本治理，这是相当于方案一最重要的一个优点，方案一很难实现多个版本的效劳共存，除非将版本治理参与命名空间。
架构缺点：
只讨论相对于方案1的缺点
需要更多的中间件，增加开发难度。
架构设计需要更多的精神。
成熟度模型的满足：
定制开发：满足度高
可配置：满足度高，配置、AOP切面编程以及流程控制效劳；
多租户：满足度中，共享数据库独立数据模型形式、共享数据库共享数据模型形式。
高性能：满足度中，多实例负载平衡、查询优化、编程优化、多进程、多线程、异步、非阻塞IO的形式满足，
伸缩性：满足度中，多数都使用同一个数据库，同一种缓存战略，相同的NOSQL。但是因为是分布式效劳，其伸缩性要比如案1要高。
技术选型建议：
JAVA > PHP > GOLANG
假设需要在可复用、易伸缩、高稳定、低延迟等企业级开发目的上得到满足，那么最好选择JAVA技术道路，此外JAVA SOA架构技术成熟度高。
假设追求开发效率，则使用PHP。PHP SOA架构通常不使用EJB，且效劳调用一般使用简单Json RPC, gRpc, hprose等简单的rpc效劳，效劳注册发现即可以使用客户端注册发现也可以使用中间件，效劳治理通常在效劳端完成，分布式一致性事务往往采用最简单的MQ队列补偿保证最终一致性，编程模型通常都是多进程、单线程，较为简单，但这些都是以牺牲一定性能换取的简单。
假设追求两者平衡，可以使用混合开发，JAVA仅做关键核心业务应用效劳，PHP可开发业务规则和业务流程的组织。
人力本钱上JAVA高于PHP， JAVA需要更多的架构，更多的懂中间件的开发者。项目可测试度JAVA仍然高于PHP。
技术方案中可能存在的不确定性：
架构师是否能按设计目的完成建模、分层分配与子系统划分；
开发组成员的素质是否能支撑领域驱动设计和单元测试；
开发组成员是否有足够分布式架构编程知识；
开发组成员是否有足够的中间件即其它与分布式有关的知识，EJB/ZOOKKEEPER/Tcc/Saga/Mq等
总结说明：
增加的设计与开发本钱可以一定提升SAAS的性能和伸缩性，并将效劳从逻辑层面和物理层面全部解耦。
方式三：微效劳（分布式）
微效劳可以看做一种特殊的SOA架构， 它和SOA相比，它去掉了EJB，并且提供更细的效劳粒度。
微效劳通常有两种架构形式，第一种客户端直联，第二种是通过API接口网关形式，对于SAAS而言，第一种可以直接放弃了。看一下第二种架构图（网上找的，实在懒得画了）：
架构特征：
效劳组件化；
按业务组织团队；
做”产品“的态度；
智能端点与哑管道（效劳调用方式，实时，异步中间件）
去中心化治理（组件能针对不同的业务特点选择不同的技术平台）
去中心化管理数据（多个不同的MySql实例，各效劳之间停止“无事务”的调用，数据一致性，只要求数据在最后的处置状态是一致的即可。补偿机制）
根底设备自动化（自动化测试、自动化部署）
容错设计（快速检测出故障资源并尽可能地自动回复效劳是必需被设计和考虑的）
演进式设计
架构优点：
容器化独立部署、扩展性强；
效劳简单，只关注一个业务功能；
效劳自冾，可以直接被外部或其他效劳调用，不像SOA需要更高层的业务逻辑组织；
每个效劳可以由不同的团队开发，并且可以使用不同的平台和语言；
松耦合；
架构缺点：
较高的运维开销；
较高的领域驱动设计和DEVOPS要求；
并行的团队开发可能会产生反复性劳动；
需要处置分布式系统的复杂性；
跨进程之间的事务、大量的异步处置、多个微效劳之间的整体测试都需要有一整套的处置方案；
成熟度模型的满足：
定制开发：满足度高
可配置：满足度高，配置、AOP切面编程以及流程控制效劳；
多租户：满足度高，共享数据库独立数据模型形式、共享数据库共享数据模型形式、独立数据库形式。
高性能：满足度高，多实例负载平衡、查询优化、编程优化、多进程、多线程、异步、非阻塞IO、容器化的形式满足，
伸缩性：满足度高，数据库拆分，独立部署的效劳，热部署。
技术选型建议：
JAVA > GOLANG > PHP
JAVA的技术成熟度最高，可选中间件最多。
GOLANG适宜从单体到微效劳的迁移，不适宜从零开端；
PHP社区的微效劳只在探究之中，教育系统常用， 可选中间件较少；
开发本钱GOLANG > JAVA > PHP， GOLANG是因为开源社区不够成熟，从业人员较少。PHP只在能招聘到技术专家的前提下开发本钱较低。
总结说明：
微效劳可能是最能满足SAAS4个成熟度模型的架构形式，但是它对团队和开发人员的素质要求较高。
当前架构选型二分检索表
简单设计了一个选择初始架构方案的检索表，因为每个架构方案都能满足可配置多租户的需求，只是对高性能和伸缩性的支持不同，所以当然从“不差钱”开端作为第一选项：
1、创业阶段，投入资金有限（<4个高程），接受架构缓慢迁移…2
1、一般土豪，资金不是问题（>=4个人高程），需要更多的为将来考虑…4
2、将来1-2年之内预设的直接用户并不多，不超越50万…A
2、将来1-2年之内预设的直接用户非常多，远高于50万…3
3、将来的业务上升曲线异常陡峭，不会有太多架构迁移时间…B
3、将来的业务不会比如今复杂太多，或上升平缓，阶段性有足够时间迁移…C
4、将来的业务异常复杂，需要高度的性能和伸缩性…D
4、将来的业务并不复杂，伸缩性和性能可满足…E
A.PHP分层可迁移架构（单体， 假设出于培养团队需要可直接上JAVA）；
B.PHP微效劳架构（分布式）；
C.PHP SOA架构（分布式）；
D.JAVA微效劳架构（分布式）；
E.JAVA SOA架构（分布式）；
选择的是初始的架构形式，阶段性架构迁移需要根据以后的情况选择，当然，一种技术道路切换到另一种，即便架构形式已经为将来留出足够迁移准备，事实上在人力和时间上仍然是一个高本钱高投入的过程，这点也是要考虑的。
PHP和JAVA的混合形式一般只适宜从PHP平台迁移至JAVA平台的团队，混合开发形式不会减少JAVA需要的分工人员，只是能协助JAVA减少一些业务逻辑表示的工作量。 |
