ToB Saas系统最近几年都很火。很多创业公司都在尝试创建企业级别的应用 cRM, HR,销售, Desk Saas系统。很多Saas创业公司也拿了大额风投。毕竟Saas相对传统软件的优势非常明显。   
 
最近一年，有幸架构一个Crm saas 系统，上线了几个月来，各方面都比满意。整个系统创建过程，踩了很多坑，收获也比较多。总结一下Saas系统架构一些特点：
 
Saas系统分级：
 
SaaS系统架构成熟度模型的5个级别——从“混乱”到“乌托邦“
 
第0级（混乱）：每次新增一个客户，都会新增软件的一个实例。
第1级（受控的混乱）：所有客户都运行在软件的同一个版本上，而且任何的定制化都通过修改配置来实现。
第2级（多租户[multi-tenant]、高层建筑[Highrise]）：所有的客户都已经可以在软件的同一个版本上运行了，而且他们都在同一个“实例”上运行。
第3级（多租户， 扩建[Build-Out]）：此时你已经拥有了多租户、单一版本的软件模型。不过你还是可以通过硬件扩展（scale-out）的方式来进行扩充。
第4级（乌托邦）：如同第3级，除非你可以找出有效的方式，以在不同的“实例”上运行不同版本的软件。
 
应用程序必须支持多租户：
 
  　　多租户可以分为几个不同的类别（如列表下方的图所示）：
  　　 1.1，云中的简单虚拟化，其中只对硬件进行共享。
   　　1.2，共享应用程序，对每个租户使用不同的数据库。
   　　1.3，共享应用程序和数据库（效率最高，真正的多租户）。
 
1.分层设计
 
Saas系统分层大概是：
 
 
 

  
  
 
 
 
 
Saas系统分层：租户识别>应用层>数据访问层>缓存层>数据库
 
业务代码都是写在应用层。
 
租户识别可以用spring拦截器实现，然后使用ThreadLocal传递给后端
 
数据库和缓存层对应用层应该是透明的。程序员在写代码的时候，只关心业务逻辑，不应该担心多租户的问题。
 
 
 
2.数据隔离要透明
 
saas系统说起来很简单，任何系统似乎加个tenant_id(租户id)就变成saas系统了。比如原来的用户登录是：
 
select username,password from users where email='abc@qq.com'
 
改成
 
select username,password from users where email='abc@qq.com' and tenant_id =1;
 
对于复杂业务的saas系统，这样做法非常危险，而且开发效率很低。你想想如果那个程序员写sql时候忘了加 “ and tenant_id =1” . 结果不堪设想。
 
比较好做法是在数据库访问层对SQL进行改写。
 
TenantContext.exec("select username,password from users where email='abc@qq.com' ");
 
在连接池根据TenatnContext改写Sql. 
 
这样做好处是，一来程序猿最多把系统搞down了，也不至于信息串了互相泄露。二来将来做分表分库也很方便，上层应用不用修改。
 
3. 租户识别方案
 
比较好做法是通过url识别租户。系统是给租户生成一个随机的三级域名，比如 abc.crm.baidu.com.   如果客户想使用自己的域名，可以在cname到我们生成的三级域名，并在管理系统里面做绑定。
 
这样一个租户可以有两个域名，访问saas,一个随机生成的三级域名，另外一个租户自己的域名.代码里面可以根据过来的域名，判断是那个租户然后初始化TenantContext.
 
如果不想通过域名来做，也可以通过登录名来判断。这种方式要涉及到租户切换问题。
 
4. 智能DNS
 
以后补充。
 
5. 租户管理系统（计费，订购，定制，充值，催缴）
 
Saas系统是必须考虑计费系统和租户控制系统。这个系统需要都是独立设计。比如那个租户购买了那些模块，一个月多少钱。租户可以创建最多的用户数。计费到期邮件提醒等功能。
 
计费方式一般有两种，周期性计费，类似月租方案，和使用量计费,用多少付多少。 周期性计费比较简单。也可以两者结合起来。
 
6. 定制化开发
 
SAAS的优势在于一套系统多人使用，似乎和定制化开发有冲突。比如A客户想要A功能，B客户不想要。但定制化开发是无法避免的，比如CRM系统这样复杂的系统，不可能一套系统满足所有公司的要求。定制化开发尽可能分系统，分模块去做。然后通过控制台中配置不同租户订购不同模块，那些模块可以在前端页面上显示。不同的子系统需要分开部署。前端可通过nginx根据url分发，比如 abc.crm.baidu.com/bi/xxx/xx这个地址，就分发到BI子系统。不要尝试OSGI去搞模块化，这个是个大坑。
 
还有开发和产品，现有需求一定要分析清楚，不要一上线发现后患无穷。新功能尽量做的独立可以配置。
 
7. 灰度升级
 
SAAS付费企业客户对系统问题都特别敏感。 为了减少升级可能出现问题的影响范围，一般都采用灰度升级策略。如果使用了url来区分不同租户，灰度升级配置就会很方便。可以配置nginx 来根据域名做分发，比如租户A（aaa.com）到实例1（版本1.0），租户B(bbb.com)到实例2(版本). 当需要域名配置非常多的时候，nginx配置文档会乱。这块时候可以考虑使用nignx_lua来写一些扩展模块。
 
8. 容量估计
 
 
 
9. Saas平台架构分层分析
 
Saas平台架构需要完成从用户申请链接saas到用户对自己购买的功能模块的应用整个过程，用户用起saas看似简单快捷，但这个过程却需要saas平台架构默默完成的非常复杂的处理过程。通过对saas平台架构的了解，可以清晰的分化数据的处理过程，让用户也可以明白saas平台架构处理数据的优势。下面介绍：saas平台架构分为哪几部分。
 
 
 
saas平台架构之呈现层：
 
saas平台架构的呈现层可以使用的客户端可能都浏览器或本地客户端。如果是浏览器则需要Web界面技术、交互技术等技术（如：HTMl5技术、CSS3技术、Ajax技术等）的支持，如果是软件客户端则需要远程桌面技术、软件交互技术等技术支持。
 
saas平台架构之调度层：
 
saas平台架构的调度层体现分布式系统的特性之一。调度层首先负责识别并通过AAA认证每个用户请求，然后根据业务处理器的负载、业务特征进行合理的调度。通过应用这样的架构SaaS平台可以横向扩展。此外在存储、缓存等方面为了满足平台的横向扩展需求，调度层也必须具有良好的可扩展性。
 
saas平台架构之业务层：
 
saas平台架构的业务层负责接收调度层转发过来的请求，而且还要通过对接受到的请求执行真正的业务逻辑。一般来说业务逻辑的执行使用一台服务器就够了。因此业务层实际是由一排对等的服务器组成的，每台服务器都执行相同的业务逻辑。
 
saas平台架构之数据层：
 
saas平台架构的数据库集群用于处理存储关系性很强并且对事务性要求很高的业务数据，这类数据目前还要用传统的数据库集群技术来解决，saas平台架构的数据库集群主要是根据业务特征制定数据拆分方案。同时分布式数据库用于存放海量但关系性不强的数据（如：用户的操作日志等）。
 
以上是对“Saas系统架构的思考，多租户Saas架构设计分析”的介绍，从saas平台架构处理数据可以看出saas平台的应用有很强的优势，如用户使用saas非常方便简单只要浏览器或本地客户端接口，saas平台处理数据要经过层层认证saas产品安全可靠，saas平台优化处理数据提高saas性能。
 
多租户Saas系统架构还应该满足以下需求：
 
编号
需求
描述
1
软件授权
云平台付费授权机制，可按时间、功能、数量等进行付费授权
2
组织入驻
允许组织主动申请加入平台
3
实名认证
个人实名认证、组织实名认证
4
资质审核
个人和组织的资质审核，如对获得的证书或荣誉进行审核
5
组织绑定
个人账户绑定组织，与组织建立关联关系
6
组织解绑
个人账户与组织进行解绑
7
账户注销
个人账户注销，并销毁所有个人资料和档案
8
统一登录
即 SSO
9
统一注册
提供统一的用户注册页面
部分资料整理自：
 
 
 
http://www.ruanally.com
​​​​​​​http://qk.gam7.com
​​​​​​​​​​​​​​http://www.ruanbe.com
 
 
 

一、软件架构设计
 
软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
 
软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件系统的组织结构和拓扑结构。
 
软件架构是可传递可复用的模型，架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配，即满足，需求的职责分配到组件上。
 
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质；能够使得不同的利益相关人（stakeholders）达成一致的目标；能够支持项目计划和项目管理等活动；能够有效地管理复杂性；等等。然而系统架构的给出必须建立在需求明确的基础上。
 
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。
 
二、架构的模型 4+1视图
 

 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。（用户关注）
 
开发视图：也称为模块(实现)视图，主要侧重于软件模块的组织和管理。（程序员）
 
进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。（并发，集成人员）
 
物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。（软件到硬件，系统工程人员）
 
场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。（用例图）
 
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
 
三、软件架构风格
 
软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式；惯用模式则反映众多系统共有的结构和语义特性。强调对软件设计的重用。
 
架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻会明白系统是如何组织和工作的。
 
1. 数据流风格
 
 
 
批处理序列
 
强调数据作为一个整体（数据必须是完整的，以整体的方式传递）
 
 
管道和过滤器
 
每个构件都有一组输入和输出,构件读输入的数据流，经过内部处理，然后产生输出数据流. (构件–>过滤器;连接件–>管道) （数据流的形式）
 
 
2. 调用/返回风格
 
 
 
主程序/子程序
 
计算构件作为子程序协作工作,由一个主程序顺序地调用这些子程序,构件通过共享存储区交换数据. 曾经作为结构化开发方法的主要选择，具有结构清晰，维护方便的特点，缺点是主子程序划分缺乏标准，较难实现不同设计人员间设计的子程序复用。
 
 
面向对象风格
 
面向对象在类的层次实现高度内聚，整个系统通过不同类的组合调用实现不同功能，便于类的复用，只是面向对象是一个通用风格，类的划分不同设计人员设计结果有很大不同，对实际架构设计指导意义不大。
 
 
层次结构风格
 
分层结构将整个系统按照抽象层次不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道，简化了系统中调用关系复杂度。允许每层用不同的方法实现，为软件重用提供了强大的支持。（二层C/S、三层C/S、MVC、MVP、MVVP、RIA富互联网应用）
 
 
3. 独立构件风格
 
 
 
进程通讯
 
进程通讯架构将系统建设成一个个独立构件，构件间采用命名的消息传递来实现沟通与协作。
 
 
事件系统子风格（隐式调用 ）
 
事件驱动架构风格与进程通讯风格类似，也是将系统分各个为独立的构件，不同的是不同构件间通讯不采用命名的消息，而是采用隐式调用的方式，先将一个个构件的过程注册到某个事件中，当这个事件发生时，所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低，方便构件修改及替换，缺点是触发事件放弃了对被触发执行程序组的控制。
 
 
4. 虚拟机风格
 
 
 
解释器
 
具有运行时系统行为 (自)定义与改变能力 。如专家系统。
 
 
基于规则的系统
 
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。（一般用在人工智能领域和DSS中）
 
 
5. 仓库风格
 
 在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。
 
 
数据库系统
 
构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态,另一个是多个独立处理元素,处理元素对数据元素进行操作。中央数据库管理系统通过自身机制如数据排它锁，共享锁等，实现数据高速访问，数据一致性，数据完整性。同时各独立数据处理单元之间互相不受约束。 (如编译器，传统编译器采用批处理架构，现代编译器采用数据共享架构风格。分析树是共享数据。)
 
 
超文本系统
 
主要应用于静态网页。
 
 
黑板风格
 
由一个作为全局共享数据的黑板，一个控制单元和多个知识源组成，主要应用与专家问题解决系统。通过专家知识和反馈逐步得到正确结果. (如语音识别)
 
 
6. 闭环控制架构
 
 
过程控制
 
工业中的过程控制是指以温度、压力、流量、液位和成分等工艺参数作为被控变量的自动控制。过程控制也称实时控制，是计算机及时的采集检测数据，按最佳值迅速地对控制对象进行自动控制和自动调节，如数控机床和生产流水线的控制等。（比如空调制冷，温度大于设定温度制冷，小于等于时停止，一旦大于继续运作）
 
 
C2
 
 
通过连接件绑定在一起按照一组规则运作的并行构件。
 
  
构建和连接件都有一个顶部和一个底部
构建的顶部都要连接连接件的底部，构建的底部都要连接连接件的顶部，构建 之间不允许直连。
一个连接进行直接连接时，必须有其中一个的底部到另一个的顶部。
 
 
四、分层C/S架构风格演化
 
1. 二层 C/S
 
 
二层 C/S 结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；(使用范围)
软、硬件的组合及集成能力有限；(扩展性)
服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；(性能)
数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。(安全)
 
2. 三层C/S架构
 
 
表现层（Web层）
 负责接收客户端请求，向客户端响应结果，通常客户端使用http协议请求 web，web层需要接收 http请求，完成http响应。
 表现层包括展示层和控制层：控制层负责接收请求，展示层负责结果的展示。
 表现层依赖业务层，接收到客户端请求一般会调用业务层进行业务处理，并将处理结果响应给客户端。
 表现层的设计一般都使用 MVC 模型。 MVC 是表现层的设计模型，和其他层没有关系。
业务层 （Service层）
 它负责业务逻辑处理，和我们开发项目的需求息息相关。web层依赖业务层，但是业务层不依赖Web层。
 业务层在业务处理时可能会依赖持久层，如果要对数据持久化需要保证事务一致性。 (事务应该放到业务层来控制）
持久层 （dao 层）
 负责数据持久化，包括数据层即数据库和数据访问层，数据库是对数据进行持久化的载体，数据访问层是业务层和持久层交互的接口；业务层需要通过数据访问层将数据持久化到数据库中。
 持久层就是和数据库交互，对数据库表进行增删改査的。
 
优点:
 
（1）允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。(逻辑独立清晰, 可维护性/可扩展性)
 
（2）允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。(可升级性/开放性)
 
（3）三层C/S架构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。(开发维护成本/速度/技术门槛)
 
（4）允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。(安全)
 
3. 三层B/S架构
 
 
用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。(客户端)
 
基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。(服务端)
 
B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。(开放性)
 
缺点:
 
B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
B/S架构的系统扩展能力差，安全性难以控制。
采用B/S架构的应用系统，在数据查询等响应速度上，要远远地低于C/S架构。(性能)
B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用.
 
五、MVC的架构风格
 
 
MVC 全名是 Model ViewController，是模型(model)－视图(view)－控制器(controller)的缩写，它是分层架构风格的一种。主要解决 将与 UI 相关的逻辑都定义在针对视图的相关元素的事件上 的问题。
 
MVC 中各个部分的分工与协作：
 
Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model 接受 Controller 的请求并完成相应的业务处理，在状态改变的时候向 View 发出相应的通知。
View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
View 捕获到用户交互操作后会直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。在完成 UI 处理后，Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。
 
六、MVP 的架构风格
 
 
MVP 是从经典的模式 MVC 演变而来，它们的基本思想有相通的地方：Controller/Presenter 负责逻辑的处理，Model 提供数据，View 负责显示。
 
当然 MVP 与 MVC 也有一些显著的区别，MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在 MVP 模式中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC 中的 Controller）来进行的，所有的交互都发生在 Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller，从而避免了 View 和 Model 之间的耦合。
 
扩展：
 
1. MVVM架构
 

 2. 富互联网应用（RIA）
 

 3. 分布式架构
 
客户机/服务器系统开发时可以采用不同的分布式计算架构：
 
分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上（类似三层CS架构的两层应用）；
分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机（类似两层CS架构）；
分布式数据和应用架构数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机（类似三层CS架构）。
 
4. ANSI
 
在ANSI/IEEE 1471-2000标准中，系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境（Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构（Architecture）是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。架构描述（Architecture Description）本质上是多视图的。每一个视图（View）是从一个特定的视角（Viewpoint）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角（Viewpoint）的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图（View）包括一个或者多个架构模型（Model），一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。
 
5. 需求和架构
 
需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。
 
6. 架构风格和设计模式的区别
 
 
架构风格往往是从全局的角度来考虑问题，他是一种独立于实际问题的通用组织结构。例如，常用的B/S架构，在很多不同的系统中，都有应用。
 
 
而设计模式着眼于解决某一特定的局部问题，是一种局部解决方案的应用。例如，在很多的软件系统中，创建对象时，希望有统一的机制对这些对象的创建进行管理，所以出现了工厂模式，创建者模式等设计模式。比如java内存垃圾的回收机制也做成了一种设计模式。
 
 
7. 软件架构需求
 
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
 
8. 面向构件的编程（COP）
 
面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP 定义如下（Szyperski，1995）： “面向构件的编程需要下列基本的支持：
 
多态性（可替代性）；
模块封装性（高层次信息的隐藏）；
后期的绑定和装载（部署独立性）；
安全性（类型和模块安全性）。”
 
系统构件组装分为三个不同的层次：定制（ Customization）、集成（Integration）、扩展（Extension）。这三个层次对应于构件组装过程中的不同任务。
 
9. OMG接口定义语言IDL
 
IDL 是一种接口定义语言，具体的定义会涉及到接口以及相关部分。文件包含的主要元素有：接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。
 
由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为Java类，而该接口的操作映射为相应的成员函数。模块定义映射为Java 语言中的包 (Package)或C++的namespaces。
 
9. 扩展知识
 
一个软件的架构设计是随着技术的不断进步而不断变化的。以编译器为例，其主流架构经历了管道-过滤器到数据共享为中心的转变过程。早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。早期的编译器采用管道-过滤器架构风格，并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分。现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示。现代的编译器采用以数据共享为中心的架构风格，分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供了帮助。

1 概述
 
         CPU架构是CPU商给CPU产品定的一个规范，主要目的是为了区分不同类型的CPU。目前市场上的CPU分类主要分有两大阵营，一个是intel、AMD为首的复杂指令集CPU，另一个是以IBM、ARM为首的精简指令集CPU。不同品牌的CPU，其产品的架构也不相同，Intel、AMD的CPU是X86架构，IBM公司的CPU是PowerPC架构，ARM公司的CPU是ARM架构，国内的飞腾CPU也是ARM架构。此外还有MPIS架构、SPARC架构、Alpha架构。
 
2 X86架构
 
        X86架构（The X86 architecture）是微处理器执行的计算机语言指令集。X86指令集是美国Intel公司为其第一块16位CPU(i8086)专门开发的，美国IBM公司1981年推出的世界第一台PC机中的CPU--i8088(i8086简化版)使用的也是X86指令。同时电脑中为提高浮点数据处理能力而增加的X87芯片系列数字协处理器则另外使用X87指令，，包括后来 Intel 80186、80286、80386以及80486，由于以“86”作为结尾，以后就将X86指令集和X87指令集统称为X86指令集。虽然随着CPU技术的不断发展，Intel陆续研制出更新型的i80386、i80486直到今天的Pentium 4(以下简为P4)系列，但为了保证电脑能继续运行以往开发的各类应用程序以保护和继承丰富的软件资源，所以Intel公司所生产的所有CPU仍然继续使用X86指令集，所以它的CPU仍属于X86系列。
 
 
       x86架构CPU主要应用领域：个人计算机、服务器等。在PC端市场Wintel组合（windows系统 + intel处理器）占据了大部分江山，另外一部分有ADM占领。目前国内有兆芯，从AMD和VIA获取授权，研发自己的X86CPU，有其它国产CPU + 国产操作系统（linux系）可以用于教育和事业单位以及军工行针对的是特殊用户，国产CPU和操作系统想进入民用市场，由于性能、价格以及生态系统等，仍需要继续优化打磨以及一个合适契机。
 
     x86指令集发展
 
       IA：Intel（英特尔）处理器的服务器称之为IA（Intel Architecture）架构服务器
 
      IA-32：英特尔32位体系架构，X86从16位到32位是在原有的架构基础上进行修改（Intel称之为IA-32）
 
      x86-32：现如今Intel把x86-32称为IA-32
 
      x86-64 分为intel和AMD
 
       AMD64：x86架构的64位拓展，向后兼容于16位及32位的x86架构。x64于1999年由AMD设计，AMD首次公开64位集以扩展给x86，称为“AMD64”，AMD64和Intel64基本上一致
 
       Intel64：EM64T（Extended Memory 64 Technology）扩展64bit内存技术，本质上和AMD64一样都是IA-32的增强版本。
 
       IA-64：64位的英特尔架构，英特尔安腾架构（Intel Itanium architecture），使用在Itanium处理器家族上的64位指令集架构，由英特尔公司与惠普公司共同开发。IA是Intel Architecture（英特尔架构）的缩写，64指64位系统。使用这种架构的CPU，包括Itanium和Itanium 2。此架构与x86及x86-64并不相容，操作系统与软件需使用IA-64专用版本。
 
       Intel推出X86架构已满40年了，同486相比，Pentium向前迈进了一大步， 而PⅡ的前进步伐则没有这么大了，X86 CPU的发展似乎已到了尽头。英特尔非常清楚，是X86指令集限制了CPU性能的进一步提高，因此，他们正同惠普共同努力开发下一代指令集架构（Instruction Set Architecture ，ISA）： EPIC(Explicitly Parallel Instruction Computing，显性并行指令计算)。对英特尔而言， IA－64（英特尔的64位架构）是下一个10到15年的架构。新的ISA将使英特尔摆脱X86架构的限制，从而设计出超越所有现有RISC CPU和X86 CPU的新型处理器。
 
3 ARM架构
 
        ARM架构，也称作进阶精简指令集机器（Advanced RISC Machine，更早称作：Acorn RISC Machine），是一个32位精简指令集（RISC）处理器架构，其广泛地使用在许多嵌入式系统设计。由于节能的特点，ARM处理器非常适用于行动通讯领域，符合其主要设计目标为低耗电的特性。（其它请参考ARM介绍）
 
        目前，ARM家族占了所有32位嵌入式处理器75%的比例，使它成为占全世界最多数的32位架构之一。ARM处理器可以在很多消费性电子产品上看到，从可携式装置（PDA、移动电话、多媒体播放器、掌上型电子游戏，和计算机）到电脑外设（硬盘、桌上型路由器）甚至在导弹的弹载计算机等军用设施中都有他的存在。在此还有一些基于ARM设计的派生产品，重要产品还包括Marvell的XScale架构和德州仪器的OMAP系列。
 
 
          ARM 授权方式：ARM 公司本身并不靠自有的设计来制造或出售 CPU ，而是将处理器架构授权给有兴趣的厂家。ARM 提供了多样的授权条款，包括售价与散播性等项目。对于授权方来说，ARM 提供了 ARM 内核的整合硬件叙述，包含完整的软件开发工具（编译器、debugger、SDK），以及针对内含 ARM CPU 硅芯片的销售权。对于无晶圆厂的授权方来说，其希望能将 ARM 内核整合到他们自行研发的芯片设计中，通常就仅针对取得一份生产就绪的智财核心技术（IP Core）认证。对这些客户来说，ARM 会释出所选的 ARM 核心的闸极电路图，连同抽象模拟模型和测试程式，以协助设计整合和验证。需求更多的客户，包括整合元件制造商（IDM）和晶圆厂家，就选择可合成的RTL（暂存器转移层级，如 Verilog）形式来取得处理器的智财权（IP）。借着可整合的 RTL，客户就有能力能进行架构上的最佳化与加强。这个方式能让设计者完成额外的设计目标（如高震荡频率、低能量耗损、指令集延伸等）而不会受限于无法更动的电路图。虽然 ARM 并不授予授权方再次出售 ARM 架构本身，但授权方可以任意地出售制品（如芯片元件、评估板、完整系统等）。商用晶圆厂是特殊例子，因为他们不仅授予能出售包含 ARM 内核的硅晶成品，对其它客户来讲，他们通常也保留重制 ARM 内核的权利。
 
        国外生产厂商：TI （德州仪器）、Samsung（三星）、Freescale（飞思卡尔）、Marvell（马维尔）、Nvidia（英伟达）、Qualcomm(高通）、STMicroelectronics(意法半导体）。
 
        国内生产厂商：华为（海思芯片）、飞腾（FT-1500、FT2000-4等CPU芯片）、兆易创新（GD32系列MCU，参考STM32系列）、瑞芯微（RK系列芯片）、联发科（台湾，天玑系列）。
 
      ARM架构的CPU可以有多核，例如几年前联发科推出10核处理器Helio X20（被戏称一核有难，八核围观，国产FT处理器已经推出了16核处理器。但是由于ARM自身低功耗等因素的限制，核心数多并不一定能大大提升性能。
 
 
       目前ARM主要市场是手机端CPU和MCU，手机CPU市场，由高通骁龙系列、华为麒麟系列、以及三星猎户系列和联发科系列，在MCU端主要是STM32以及国产的GD32，其它厂商的芯片用于其它领域，比如汽车电子、智能家居等。在CPU处理器上，有华为海思的鲲鹏920CPU（应用于泰山服务器中）和FT的CPU（军工领域），虽然FT的CPU起步很早，但是鲲鹏显然有后来居上之趋势。国内ARM芯片做的最好的是华为海思，鲲鹏920CPU性能在ARM架构中是NO1，另外海思麒麟系列手机芯片已发展为全球前三的地位，海思的视频处理芯片以及IoT芯片，在行业中都是标杆的产品。
 
      在2020年11月11日，apple公司发布了新一代的mac book，亮点就是使用了apple自己的ARM架构的M1。由于ARM的功耗小，在新一代的macbook上，apple大胆的去掉了散热风扇芯片，将笔记本厚度进一步压缩，续航时间达到了18小时。同时，搭载M1芯片的mac book CPU 性能提升至 3.5 倍，GPU 性能提升至 5 倍，机器学习性能提升至 9 倍。根据apple公司的影响力，未来PC中市场将会被ARM架构的CPU替代。（天下苦wintel久已）
 
4 MPIS架构
 
       MIPS是世界上很流行的一种RISC处理器。MIPS的意思是“无内部互锁流水级的微处理器”(Microprocessor without interlockedpipedstages)，其机制是尽量利用软件办法避免流水线中的数据相关问题。它最早是在80年代初期由斯坦福(Stanford)大学Hennessy教授领导的研究小组研制出来的。MIPS公司的R系列就是在此基础上开发的RISC工业产品的微处理器。这些系列产品为很多计算机公司采用构成各种工作站和计算机系统。
 
        MIPS技术公司是美国著名的芯片设计公司，它采用精简指令系统计算结构(RISC)来设计芯片。和英特尔采用的复杂指令系统计算结构(CISC)相比，RISC具有设计更简单、设计周期更短等优点，并可以应用更多先进的技术，开发更快的下一代处理器。MIPS是出现最早的商业RISC架构芯片之一，新的架构集成了所有原来MIPS指令集，并增加了许多更强大的功能。MIPS自己只进行CPU的设计，之后把设计方案授权给客户，使得客户能够制造出高性能的CPU。
 
       1984年，MIPS计算机公司成立，开始设计RISC处理器；
 
       1986年推出R2000处理器。
 
       1992年，SGI收购了MIPS计算机公司。
 
       1988年推R3000处理器。
 
      1991年推出第一款64位商用微处器R4000；之后又陆续推出R8000（于1994年）、R10000（于1996年）和R12000（于1997年）等型号。
 
      1998年，MIPS脱离SGI，成为MIPS技术公司；随后，MIPS公司的战略发生变化，把重点放在嵌入式系统；1998年－MIPS科技股票在美国纳斯达克股票交易所公开上市。
 
      1999年，MIPS公司发布MIPS32和MIPS64架构标准，为未来MIPS处理器的开发奠定了基础。新的架构集成了所有原来NIPS指令集，并且增加了许多更强大的功能。MIPS公司陆续开发了高性能、低功耗的32位处理器内核（core）MIPS324Kc与高性能64位处理器内核MIPS645Kc。
 
      2000年，MIPS公司发布了针对MIPS32 4Kc的版本以及64位MIPS 64 20Kc处理器内核。
 
      2007年8月16日－MIPS科技宣布，中科院计算机研究所的龙芯中央处理器获得其处理器IP的全部专利和总线、指令集授权。
 
      2007年12月20日－MIPS科技宣布，扬智科技已取得其针对先进多媒体所设计的可定制化系统单芯片（SoC）核心“MIPS32 24KEcPro”授权。
 
 
       MPIS架构授权和ARM架构授权不一样，ARM架构授权用户基本不能自行修改，而MPIS架构授权后，可以自己修改。目前MPIS发扬光大寄希望中科龙芯公司，龙芯处理器从龙芯1号，到现在的龙芯3号系列的3A4000，CPU的性能已经大幅度提高，在完全可以胜任日常办公或者作为特殊用途的服务器。龙芯CPU和国产的飞腾（FT）处理器并驾齐驱，发展我国自主可控CPU。
 
5 PowerPC系列
 
         PowerPC 是一种精简指令集（RISC）架构的中央处理器（CPU），其基本的设计源自IBM（国际商用机器公司）的IBMPowerPC 601 微处理器POWER（PerformanceOptimized With Enhanced RISC；《IBM Connect 电子报》2007年8月号译为“增强RISC性能优化”）架构。二十世纪九十年代，IBM(国际商用机器公司)、Apple（苹果公司）和Motorola（摩托罗拉）公司开发PowerPC芯片成功，并制造出基于PowerPC的多处理器计算机。PowerPC架构的特点是可伸缩性好、方便灵活。
 
 
        PowerPC 处理器有广泛的实现范围，包括从诸如 Power4 那样的高端服务器CPU 到嵌入式 CPU 市场（任天堂Gamecube 使用了 PowerPC）。PowerPC处理器有非常强的嵌入式表现，因为它具有优异的性能、较低的能量损耗以及较低的散热量。除了象串行和以太网控制器那样的集成 I/O，该嵌入式处理器与“台式机”CPU 存在非常显著的区别。
 
 
 
6 SPARC架构
 
       SPARC架构（Scalable Processor ARChitecture，可扩展处理器架构）是国际上流行的RISC处理器体系架构之一，SPRAC如今已发展成为一个开放的标准，任何机构或个人均可研究或开发基于SPRAC架构的产品，而无需交纳版权费。SPARC 处理器架构具备精简指令集（RISC）、支持32 位/64 位指令精度，架构运行稳定、可扩展性优良、体系标准开放等特点。SPARC因此得以迅速发展壮大，在现在已经有大约3万多个成功的应用案例。
 
 
         SPARCV7/V8 是目前嵌入式控制系统常用的处理器标准版本，并在航天设备的电子系统中得到广泛应用。然而，SPARC只是一个处理器的架构标准，并不提供现成的源码或IP核，具体的芯片实现要由开发者去完成。
 
         运行Oracle Solaris的Oracle SPARC T4服务器提供了创世界纪录的性能，其单线程性能提高了5倍、内存容量高达2 TB且实现了极高的系统吞吐量和I/O容量。SPARC T4服务器适用于需要极高的可靠性、可用性和集成式片上加密加速的企业应用程序和任务关键型应用程序，可确保最终的安全性。
 
7 Alpha架构
 
        Alpha处理器最早由DEC公司设计制造，在Compaq(康柏）公司收购DEC之后，Alpha处理器继续得到发展，并且应用于许多高档的Compaq服务器上。自1995年开始开发了21164芯片，那时的工艺为0.5um，主频为200MHz。1998年，推出新型号21264，当时的主频是600MHz。较新的21264芯片主频达到1GHz，工艺为0.18um。在该芯片具有完善的指令预测能力和很高的存储系统带宽（超过1GB/s），并且其中增加了处理视频信息的功能，其多媒体处理能力得到了增强。
 
      Alpha架构于1992年2月25日，在东京召开的一次会议上面被正式推介，新架构的关键特性都一一的被罗列出来。当时说Alpha只是产品开发的内部代号。新处理器采用完全64-bit RISC设计，执行固定长度指令(32 bits)。有32个64 bit整数寄存器，操作43-bit的虚拟地址(在后来能够扩充到64-bit)。和VAX相同，使用little-endian字节顺序，即低字节的寄存器占用低内存地址线。而不像如摩托罗拉等大多数处理器所使用的big-endian字节顺序，即低字节寄存器占用高内存地址线。除此之外，处理器还内建一个算术协处理器，有32个浮点64-bit寄存器，采用随机存取，而不是在intel x86协处理器上使用的堆栈存取方式。整个Alpha的生命周期被设计为至少25年。
 
        Alpha处理器被用于DEC自己的工作站和服务器中。作为VAX的后续被开发，支持VMS操作系统，如 Digital UNIX。不久之后开放源代码的操作系统也可以在其上运行，如Linux和 DSB 。Microsoft 支持这款处理器，直到Windows NT 4.0 SP6 ，但是从Windows 2000 RC2开始放弃了对Alpha的支持。
 
 
    目前国内采用此架构的是申微超算处理器，得益于国家的支持，申威处理器在军队应用广泛。
 
8 架构之间的竞争
 
8.1 PC和服务竞争
 
         PC端和服务器端是X86架构的天下，而X86架构基本是以Intel为首，AMD为辅二分天下之势。国产CPU基本只能用在军工行业或者事业单位等。其实说性能，powerpc，可谓是高出不胜寒。硬件方面，Power系统在可靠性、可用性和可维护性的方面的出色表现使得 IBM从芯片到系统所设计的整机方案有着独有的优势。Power架构的处理器在超算、大型企业的UNIX服务器等多个方面应用也十分成功。在软件方面，其专用的AIX系统在稳定性、软件方案集成度和厂商技术支持能力方面都要更强。由于用户选一平台主要看软件需求，一般对数据保护和7*24小时不宕机等有所要求，power架构的稳定性和运维等方面相对更优。但是，由于IBM的技术把控，使得其价格太不友好，同时技术也赶不上环境的变化，在云计算兴起后，随着分布式系统逐渐成熟，系统对小型机的依赖开始降低，改为依靠集群提供，性能也可实现分布式处理。而更为关键的是，IBM的全套服务尽管稳定性优秀，但却影响了Power架构对其他商家的吸引力。
 
        而Sparc架构和Power架构基本犯了同样的错误：价格不友好。SPARC架构测成功和Sun旗下的Solaris系统有着密不可分的关系。当计算机系统庞大、用户数量巨大增加时，基于Unix操作系统打造的 Solaris能更好地利用计算机资源，是所有商业版中最可靠最完善的版本。而依赖SPARC架构和Solaris系统的性能和可靠性，其占领了服务器高端市场。Sun的另一个更为知名的产品是Java，虽然在上世纪90年代为智能家电开发的Java并没有为其带来相应的回报，但已成为今天移动时代最重要的开发语言。如此强大的实力本应统领服务器市场，但遗憾的是，在windows和英特尔组成Wintel联盟之后，两者凭借自身在各自市场的规模效应，使得采用Wintel产品的服务器厂商可以通过低廉的价格大肆抢占中低端市场。而当Sun醒悟过来，通过开源等方式想要挽回败局时为时已晚。
 
        X86架构与Power和SPARC在高性能领域的风生水起不同，x86架构是天生的小屌丝。1978年他出生的那年，英特尔还只是一个普通的科技公司。可是x86架构随同其cisc指令集却开启了一个新的时代。x86之所以可以赢得市场主要原因在于其是一个十分开放的架构。IBM和SUN当年都是从芯片到服务器到系统一手包办的公司。而英特尔则是一个十分纯粹的芯片厂商，其业务仅与AMD等少数芯片生产者存在竞争，这就使得服务器厂商不用忌惮与之发生竞争关系。
 
        单从性能来看，无论Power还是SPARC架构都可以击溃x86，可是最终能够赢下来的却偏偏是"最弱"的x86架构。这并非劣币淘汰良币，而是市场竞争的选择，根源上讲，x86的成功在于英特尔根本不碰服务器。因此不论设备生产商、软件开发者或者系统开发者都可以与不存在利益竞争关系的英特尔合作。受益于此，x86架构的兼容性也越发强大，生态体系越发完善，这才成就了现如今市场占有率超过90%的一家独大局面，英特尔也借助x86架构一跃成为全球顶级的芯片提供商。
 
8.2 移动端竞争
 
        正如PC和服务器端是X86的天下一样，移动端是ARM的天下。Intel在CPU界的大名，可谓家喻户晓，但是在手机登移动端却难以看到英国ARM公司背影。在2006年，自从AMD的64位处理器发布以来，AMD成功逆袭了Intel，市场占有率大幅上升，而Intel老迈的P4处理器则是腹背受敌，尽失昔日霸气，市场表现一路走低。为了稳住投资人的信心，最好的做法自然是让公司持续盈利，为此Intel进行大规模的重整，包括上任新CEO 欧德宁、大规模裁员、以及出售XScale手机处理器业务。正因为这个举措，使得Intel到达了人生巅峰，从PC市场有赚的钵满盆满，然而也是因为此，Intel忽视了移动领域的迅猛发展。（当年，Intel拒绝了乔帮主还是PPT的Iphone手机，不然是否就会不一样？但是想一下Iphone X 使用Intel基带，信号差的诟病，Intel做手机芯是否会臭名昭著也未可知）
 
        和Intel公司不同， ARM公司不制造，不销售芯片，而是只自己设计IP核，包括指令集架构、微处理器、GPU、互连架构等，然后谁想用就授权卖给谁，再从每颗实际造出来的产品中收取版税。ARM有三种授权模式，分别是架构授权、内核授权、使用授权，分别对应大中小公司，非常讨喜，贴个牌子就能说是自己的CPU，为ARM处理器的广泛使用打下坚实基础。
 
        ARM的成功除了商业模式的独特之外还少不得自身素质的优秀，Intel技术毫无疑问是顶尖的，但应用场景在传统PC上，换成移动设备就行不通了，移动设备比起性能首先要考虑功耗和续航，Intel就吃了这个大亏，X86架构独步天下肯定是不能随意变改的，移动设备当然继续沿用X86架构，然而换来却是高功耗和快速掉电，换谁都看不上。反之功耗控制则是ARM的强项，使用精简指令集（RISC）和创新的big.LITTLE架构，使ARM处理器能耗比一直领先于Intel。
 
        Intel正在积极布局，推出应用于 IoT 物联网的 Atom E3900 及车载电子的 Atom A3900 系列，号称 CPU 性能提升70%，GPU 性能提升190%，其中 Atom A3900 特别针对高温环境设计，可在110°C高温下使用15年。Intel是一家伟大的企业，但也是会犯错误的，既然已经错失移动市场，不妨暂时脱离，提前做好下一阶段的技术研发（5G），也有可能实现弯道超车。
 
 
 
 

软件开发就是把一个复杂的问题分解为一系列简单的问题，再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战，就是即能够快速高效地针对需求、环境的变化做出改变，也能够持续提供稳定、高可用的服务。而软件架构，就是软件系统的骨骼与框架。
 
所谓架构，见仁见智，很难有一个明确或标准的定义；但架构并非镜花水月或阳春白雪，有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件，都需要设计和架构。抽象而言，架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作，结构良好的创造活动要优于毫无结构的创造活动。
 
软件架构的核心价值，即是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图，它描述的对象是直接构成系统的抽象组件；各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。架构师的职责是努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构；能够进行系统分解形成整体架构，能够正确的技术选型，能够制定技术规格说明并有效推动实施落地。
 
软件架构分类
 
在笔者的知识体系中，实际上将架构分为业务架构、应用架构、基础架构这几大类，业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。往往可以将软件架构，分为以下几类：
 
业务架构/解决方案架构：核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代，交付总体架构。
应用架构：根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。
数据架构：专注于构建数据中台，统一数据定义规范，标准化数据表达，形成有效易维护的数据资产。打造统一的大数据处理平台，包括数据可视化运营平台、数据共享平台、数据权限管理平台等。
中间件架构：专注于中间件系统的构建，需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP 之间进行权衡。
运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。
物理架构：物理架构关注软件元件是如何放到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。
单体分层架构
 
在 Web 应用程序发展的早期，大部分工程是将所有的服务端功能模块打包到单个巨石型（Monolith）应用中，譬如很多企业的 Java 应用程序打包为 war 包，最终会形成如下的架构：
 
 
 
 
巨石型应用易于搭建开发环境、易于测试、易于部署；其缺陷也非常明显，无法进行局部改动与部署，编译时间过长，回归测试周期过长，开发效率降低等。集中式架构分为标准的三层：数据访问层、服务层和 Web 层。
 
在 Web2.0 时代刚刚流行的时候，互联网应用与企业级应用并没有本质的区别，集中式架构分为标准的三层：数据访问层、服务层和 Web 层。
 
数据访问层用于定义数据访问接口，实现对真实数据库的访问；
服务层用于对应用业务逻辑进行处理；
Web 层用于处理异常、逻辑跳转控制、页面渲染模板等。
SOA 面向服务架构
 
SOA（Service-Oriented Architecture） 面向服务架构，是在互联网应用规模迅速增长，集中式架构已无法做到无限制地提升系统的吞吐量的背景下，产生的模块化开发、分布式扩展部署等相对宽泛的概念。
 
SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口联系起来。SOA 中的接口独立于实现服务的硬件平台、编程语言，采用中立的方式进行定义，这使得构建在各系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
 
 
 
MSA 微服务架构
 
微服务（Microservices Architecture Pattern）由 Martin Fowler 在 2014 年提出的，是希望将某个单一的单体应用，转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律（Conway’s Law）所言，任何组织在设计一套系统（广义概念）时，所交付的设计方案在结构上都与该组织的通信结构保持一致，微服务与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的变化。
 
 
 
 
 
 
对于微服务，不同背景的人也有不同的见解，对于熟悉 SOA 的开发者，微服务是去中心化的分布式软件架构。SOA 更多强调重用，而微服务偏向于重写。SOA 偏向水平服务，微服务偏向垂直服务；SOA 偏向自上而下的设计，微服务偏向自下而上的设计。
 
微服务与软件工程，面向对象设计中的原理同样相通，都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。
 
Cloud Native 云原生架构
 

 云原生是通过构建团队、文化和技术，利用自动化和架构来管理系统的复杂性和解放生产力。
 
 — Joe Beda，Heotio CTO，联合创始人
 
 
 
 
 
 
Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：符合 12 Factors 应用、面向微服务架构、自服务敏捷架构、基于 API 的协作以及抗脆弱性。2015 年 Google 主导成立了云原生计算基金会（CNCF），起初 CNCF 对云原生（Cloud Native）的定义包含以下三个方面：应用容器化、面向微服务架构、应用支持容器的编排调度。
 
云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序；这意味着，如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上，我们的应用程序就是云原生的。随着公共云将承载越来越多的算力，未来云计算将是主流的 IT 能力交付方式，CNCF 也对云原生进行了重新定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用；云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
 
Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。
Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。
Serverless 对应的则是服务运维，有了 Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容
这些技术组合搭配，能够构建容错性好、易于管理和便于观察的松耦合系统；再结合可靠的自动化手段，云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。由此可见，云原生是保障系统能力灵动性地有效抓手；云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。微服务架构非常适合云原生应用程序；但是，云原生同样存在着一定的限制，如果你的云原生应用程序部署在 AWS 等公有云上，则云原生 API 不是跨云平台的。
 
 
 
 
 
 
云原生应用的关键属性包括了：使用轻量级的容器打包、使用最合适的语言和框架开发、以松耦合的微服务方式设计、以 API 为中心的交互和协作、无状态和有状态服务在架构上界限清晰、不依赖于底层操作系统和服务器、部署在自服务、弹性的云基础设施上、通过敏捷的 DevOps 流程管理、自动化能力、通过定义和策略驱动的资源分配。云原生是分布式应用当下重要的发展路径，其终态应当是 Distributionless，所有与分布式相关的问题由云平台解，分布式应用的开发会跟传统应用的开发一样方便，甚至更加便捷。
 
云基础架构
 
 
 
 
虚拟机
 
虚拟机由某些特定的硬件和内核虚拟化组成，运行客户操作系统。称为管理程序的软件创建虚拟化硬件，其可以包括虚拟磁盘，虚拟网络接口，虚拟 CPU 等。虚拟机还包括可以与此虚拟硬件通信的内核。管理程序可以托管，这意味着它是一些在主机操作系统（MacOS）上运行的软件，如示例中所示。它也可以是裸机，直接在机器硬件上运行（替换你的操作系统）。无论哪种方式，管理程序方法都被认为是重量级的，因为它需要虚拟化多个部分（如果不是全部硬件和内核）。
 
 
 
 
VM 需要硬件虚拟化才能实现机器级隔离，而容器则只需要在同一操作系统内进行隔离操作。 随着隔离空间数量的增加，开销差异变得非常明显。
 
容器
 
在过去几年里，云平台发展迅速，但其中困扰运维工程师最多的，是需要为各种迥异的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。
 
 
 
 
 
 
Docker 的出现成为了软件开发行业新的分水岭，容器技术的成熟也标志着技术新纪元的开启。Docker 提供了让开发工程师可以将应用和依赖封装到一个可移植的容器中的能力，这项举措使得 Docker 大有席卷整个软件行业并且进而改变行业游戏规则的趋势，这像极了当年智能手机刚出现时的场景——改变了整个手机行业的游戏规则。Docker 通过集装箱式的封装方式，让开发工程师和运维工程师都能够以 Docker 所提供的镜像分发的标准化方式发布应用，使得异构语言不再是捆绑团队的枷锁。
 
 
 
 
容器是包含应用程序代码，配置和依赖关系的软件包，可提供运营效率和生产力。容器为我们提供了可预测的，可重复的和不可变的运行预期，容器的兴起是 DevOps 即服务的一个巨大推动因素，可以克服当今面临的最大安全障碍。容器化通过在操作系统级别进行虚拟化来使应用程序可移植，从而创建基于内核的隔离的封装系统。容器化的应用程序可以放在任何地方，无需依赖项运行或需要整个 VM，从而消除了依赖关系。
 
作为独立的单元，容器能够在任何主机操作系统，CentOS，Ubuntu，MacOS，甚至是像 Windows 这样的非 UNIX 系统中运行。容器还充当标准化的工作或计算单元。一个常见的范例是每个容器运行单个 Web 服务器，数据库的单个分片或单个 Spark 工作程序等，只需要扩展容器的数量就能够便捷地扩展应用。每个容器都有一个固定的资源配置（CPU，RAM，线程数等），并且扩展应用程序需要只扩展容器的数量而不是单个资源原语。当应用程序需要按比例放大或缩小时，这为工程师提供了更容易的抽象。容器也是实现微服务架构的一个很好的工具，每个微服务只是一组协作容器。例如，可以使用单个主容器和多个从容器来实现 Redis 微服务。
 
Kubernetes 与编排
 
随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多地提及。IaaS、PaaS 和 SaaS 是云计算的三种基本服务类型，分别表示关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务，以及关注业务应用的软件即服务。容器的出现，使原有的基于虚拟机的云主机应用，彻底转变为更加灵活和轻量的容器与编排调度的云平台应用。
 
 
然而容器单元越来越散落使得管理成本逐渐上升，大家对容器编排工具的需求前所未有的强烈，Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力，它们是云平台上的分布式操作系统。容器编排是通常可以部署多个容器以通过自动化实现应用程序的过程。像 Kubernetes 和 Docker Swarm 这样的容器管理和容器编排引擎，使用户能够指导容器部署并自动执行更新，运行状况监视和故障转移过程。
 
Kubernetes 是目前世界范围内关注度最高的开源项目，它是一个出色的容器编排系统，用于提供一站式服务。Kubernetes 出身于互联网行业巨头 Google，它借鉴了由上百位工程师花费十多年时间打造的 Borg 系统的理念，安装极其简易，网络层对接方式十分灵活。Kubernetes 和 Mesos 的出色表现给行业中各类工程师的工作模式带来了颠覆性的改变。他们再也不用关注每一台服务器，当服务器出现问题时，只要将其换掉即可。业务开发工程师不必再过分关注非功能需求，只需专注自己的业务领域即可。而中间件开发工程师则需要开发出健壮的云原生中间件，用来连接业务应用与云平台。
 
Kubernetes、Service Mesh 和 Serverless 三者共同演绎不同层次的封装和向上屏蔽下面的细节。Kubernetes 引入了不同的设计模式，实现对各种云资源全新、有效和优雅的抽象和管理模式，让集群的管理和应用发布变成了件相当轻松且不易出错的事。被广泛采用的微服务软件架构将分布式应用的各种复杂度迁移到了服务之间，如何通过全局一致、体系化、规范化和无侵入的手段进行治理就变成了微服务软件架构下至关重要的内容。Kubernetes 细化的应用程序的分解粒度，同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能，简化了应用程序的开发。而 Kubernetes 这种声明式配置尤其适合 CI/CD 流程，况且现在还有如 Helm、Draft、Spinnaker、Skaffold 等开源工具可以帮助我们发布 Kuberentes 应用。
 
 
Service Mesh 通过将各服务所共用和与环境相关的内容剥离到部署于每个服务边上的 Sidecar 进程而轻松地做到了。这一剥离动作使得服务与平台能充分解耦而方便各自演进与发展，也使得服务变轻而有助于改善服务启停的及时性。Service Mesh 因为将那些服务治理相关的逻辑剥离到了 Sidecar 中且作为独立进程，所以 Sidecar 所实现的功能天然地支持多语言，为上面的服务采用多语言开发创造了更为有利的条件。通过 Service Mesh 对整个网络的服务流量进行技术收口，让异地多活这样涉及流量调度的系统工程实现起来更加优雅、简洁与有效，也能更加方便地实现服务版本升级时的灰度、回滚而改善安全生产质量。由于技术收口，给服务流量的治理和演进、排错、日志采集的经济性等疑难问题创造了新的发展空间。
 
 
 
 
 
 
 
 
 
欢迎关注公众号：“架构一线”，定期分享一些实战心得，互联网前沿技术等.