SaaS的几种架构解析
SAAS成熟度模型分级
L1 定制开发
软硬件都由SAAS服务商提供，软件的使用者只需要按时间、用户数、空间等逐步支付租赁使用费用即可
L2 可配置
通过不同的配置满足不同用户的需求，而不需要为每个用户进行特定定制，以降低定制开发的成本。
L3 高性能的多租户架构
多租户：通过一定的策略来保证不同租户间的数据隔离，确保不同租户即能共享同一个应用的运行实例，又能为用户提供独立的应用体验和数据空间。实现方案有独立数据库、共享数据库独立数据架构、共享数据库共享数据架构。
高性能：满足多租户并发访问的性能挑战。
L4 可伸缩性的多租户架构
解决租户数量增加因集中式数据库带来的性能瓶颈。
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个成熟度模型的架构模式，但是它对团队和开发人员的素质要求较高。