SAAS Platform Architecture

1 General Idea

1.1 What is SAAS platform?

SaaS是Software-as-a-Service（软件即服务）的简称，随着互联网技术的发展和应用软件的成熟， 是一种完全创新的软件应用模式。

特点：

• 服务的收费方式风险小，灵活选择模块，备份，维护，安全，升级
• 让客户更专注核心业务
• 灵活启用和暂停，随时随地都可使用
• 按需定购，选择更加自由
• 产品更新速度加快
• 市场空间增大
• 订阅式的月费模式
• 有效降低营销成本
• 准面对面使用指导
• 在全球各地，7*24全天候网络服务
• 不需要额外增加专业的IT人员
• 大大降低客户的总体拥有成本

目的：
SaaS通过Internet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。用户不用再购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件，软件厂商在向客户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的软件和服务。
SaaS 应用软件的价格通常为“全包”费用，囊括了通常的应用软件许可证费、软件维护费以及技术支持费，将其统一为每个用户的月度租用费。 对于广大中小型企业来说，SaaS是采用先进技术实施信息化的最好途径。但SaaS绝不仅仅适用于中小型企业，所有规模的企业都可以从SaaS中获利。

使用场景：

• 实际上saas主要在CRM软件领域应用广泛。
• 另外，进销存，物流软件等也是一种应用。
• 更广义的是工具化SaaS，比如视频会议租用等，企业邮箱等成为SaaS应用的主要应用。

对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要。

1.2 What is Micro Service?

先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（整体的复杂系统）。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

Monolithic比较适合小项目，优点是：

• 开发简单直接，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理开销和调用开销

它的缺点也非常明显，特别对于互联网公司来说：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求

所以，现在主流的设计一般会采用Microservice Architecture，就是基于微服务的架构。简单来说， 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

Micro services最大特点是自治。和传统的系统比较，它将系统划分成若干个子系统分而自治。

Micro services的优点：
模块化开发，解耦和，
和传统系统相比，降低了单一模块复杂度
传统系统只能用特定语言和framework开发；而微服务适合异构开发，可以用多种语言framework。
传统系统依赖库庞大而复杂，容易引起冲突；微服务依赖库独立管理，而且互相隔离不易引起冲突。
传统系统部署方式单一；微服务适合多种部署方式
传统系统存在单一模块fail风险，如果内存泄漏导致服务器宕机；微服务可以有效防止单一模块宕机风险，把风险分散到各个模块。
传统系统逻辑复杂，多team协作开发难道很大；微服务由于给个模块功能相对简单，适合多team协作开发（不同team有各自独立的开发管理生命周期等等）

缺点：
增加模块间通信的复杂度
部署启动方式多样，比较繁琐
需要有比较好的infra管理，对于小系统并不适用

1.3 What is Component Architecture?

1.3.1 Introduction

组件架构指整个系统由一个个组件组成，每个 组件是一个独立的功能模块。

组件架构其实就是micro services架构。

通过组件化，可以极大的实现重用性， 提高开发效率，快速灵活应对业务需求，通过降低耦合度提升系统的可管理性， 从而降低维护成本，是一个高可靠的开发方案。

具体特点可以参照micro services。

1.3.2 Component Spec

Drone里的组件每个可分为4层对应4个模块，分层的目的是解耦合。

具体模块如下：

• api

定义组件接口，只对impl和client可见。这里client调用component 。

• impl

组件接口的实现。依赖api模块。如果组件依赖其他组件C1，也需要依赖C1的api,但不依赖C1的impl.

• autoconfigure 

todo:

• starter

如果组件可以作为server启动，就包括starter模块。

Starter模块依赖组件的api,impl,autoconfig模块。如果组件依赖其他组件C1，也需要依赖C1的api,impl,autoconfig模块。

Example：

如图所示：

组件内的依赖关系是上层依赖下层。

组件间，组件A依赖组件Config，所以组件A的impl要依赖Config的api,但不依赖Config的impl。

组件A的starter因为是实际启动模块，所以依赖组件A和config的所有模块。

2 Component Oriented Architecture

2.1 Overview

2.2 Platform Core

2.3 Providers

2.4 Platform Services

2.5 Monitoring

2.6 Cloud Infrastructure

3 Platform Core Architecture

3.1 Kernel

3.1.1 Utils

3.1.1 Config

3.1.2 Cache

3.2 Platform Provider

3.2.1 DAO

3.2.2 Service

3.3.3 Log

3.3 Platform Services

3.3.1 Query As A Service

3.3.1.1 Engine

3.3.1.2 Distributor

3.3.1.3 Aggregrator

3.3.2 Workflow As A Service

4 Performance Monitor

4.1 Metrics Collector

4.2 Health Check

5 Infrastructure

5.1 Containerization

5.2 Clustering Management

5.3 Storage

6 PDLC

6.1 Project Initialization

6.2 Deployment

6.3 Regression Testing

6.4 Patching