Azure ARM架构深度解析
从产品组一直走到Azure的落地，这一路也见证Azure从产品线到落地这一路的风风光光。也见证了Azure 从Manage Portal 到新Portal这一路的起起落落，不知不觉中在Satya的领导下，Azure后发制人跑到行业的前列，前途一片光明！
同样的也领悟到做Azure落地者所不能懂得Azure设计者，设计灵魂的所在，
同样的也领悟到做Azure产品者所不能懂得Azure落地者，实施灵魂的所在，
就像白天不懂夜的黑一样，因为产品者---->落地者，肯定是不能互通的，这也是作为一个商业公司Microsoft必须做的功课哈，大家理解就好了！
接下来我们就探讨下Azure Resource Manager(ARM) 和 Azure Service Management(ASM)的差别，以及ARM的架构。
什么是资源，资源就可以理解为Azure中的一些对象，例如：VM, Vnet, CS, Batch, WebApp, LogicApp,……
[*]资源在Azure中探讨
ASM:
1：混合对象的管理方式，并且都同属于一个管理实例中。
2：必须能连接到一个经典VNet的基础设施。
ARM:
1：单个对象管理方式，可以单独管理。
2：必须能连接到一个RM VNet的基础设施。
3：所有新部署强制采用Resource Groups模式。
那么问题来了，也许小伙伴们会问什么是Resource Groups ?
[*]Resource Groups
1：容器性，具有高耦合性可以存放多个相同，相似，或者不通的类型的资源
2：唯一性，每个资源必须，必须存在一个，仅仅一个Resource Group中。
3：跨区域性，一个Resource Group中可以包含不同区域的资源。
4：零嵌套性，Resource Group不能包含Resource Group。
5：高权限性，仅仅只能有Subscription Owner才可以创建Resource Group。
为什么要采用Resource Group的方式管理，有的人说抄袭AWS，我保持沉默，因为Resource
Group模式有自己独到的优势，再者，重要的是将来的Azure Stack 和Azure统一埋下伏笔。
[*] ARM在Azure上的架构如下图：
[*]角色控制策略
也许大家还不能明白角色控制是什么？角色控制也是在新Portal上对资源细化，最小权限控制的体现。看下图一个新Potral一张图来说明权限控制的问题。
上图是基于Resource(类型VM)截的图，下面我们介绍下三种典型的角色意义和权限。
所有者：可以执行所有资源及其子资源管理操作包括访问管理和授权访问。
参与者：可以执行所有资源管理操作包括创建和删除资源。一个参与者不能授权访问其它的。
读者：拥有资源及其子资源的只读访问。
为什么说这三个类型典型呢，因为从资源层控制，无论是从Resource Group还是小到资源对象，例如VM都包含这三个角色，又称为基本Role。
Note：由于Role的细化，所以Rest API也跟着相应的变化，开发者需要注意！
[*]资源锁
为什么有资源锁这么个概念呢？原因是这样的在ARM新的模式下所有的资源都是采用资源组容器的形式管理。
如果没有锁，例如资源组Resource Group1，没有加锁，那么，我一键就能删除了，不管Resource Group1 内的VM运行状态也好，什么状态也好全部都会删除。
资源锁：
1：资源锁防止事故发生。
2：资源锁允许管理员创建的策略防止写操作或防止意外删除。
如下图：
锁名为12：策略为只读，那么有了这一个锁，这个VM需要更改任何东西，系统都会阻止，会提醒先删除锁在操作！
Note：那么我有时候误删了资源组怎么办？在删除资源组的时候有两个确认过程
1：输入组名点击确认
2：是否保留资源，可以打勾，如果打勾之后，是可以恢复(可能还没有GA)
所以，一定要上锁，数据的重要性！
讲了这么多ARM和ASM区别真的很大么？
一个典型的例子：
ASM和ARM 中IaaS VM的架构图：
在ARM中是不是没有Cloud Service影子了，哈哈，容器的作用么，有GP了，另一方面产品更细化了，看什么场景了，同样完全可以把图一ASM架构里的所有都放到一个GP里，
但是有人说微软丢弃了Cloud Service，你觉得会么？答案肯定是No.
更多的东西的挖掘还得由大家来完成！
转载请说明出处，谢谢！
页:
[1]