Dynamics CRM 安全模型的性能问题

　　性能问题对系统的影响可以是致命性的，一旦不重视，在不久的将来随时可能爆发，导致系统卡顿甚至无法操作，即时重启也无济于事；甚至极其难以发现。这里为自己记录一下过往的经验。系统一开始的设计，很大程度上决定了系统的生命周期，未来能使用多久，而不用花钱改造，好的设计也会大大减少维护成本。

　　简单说下Dynamics CRM的权限，如果某个用户对某条记录具有读取权限，Dynamics CRM 会把当前用户的用户ID、部门ID、实体ID，权限层级作为一条记录记录在表SystemUserBusinessUnitEntityMap里面，因此，在创建或分派记录的时候，都会对这个表进行操作（增加或删除记录），包括更改业务部门。反过来，系统会先查询SystemUserBusinessUnitEntityMap表，以确定当前用户是否对某条记录具有读取权限。例如在视图中展示记录的时候，系统会默认先查询SystemUserBusinessUnitEntityMap表的记录以确认当前用户具有哪些记录的读取权限，如果这个表过大，则会影响查询性能。除了owner属性之外，Dynamics CRM还支持共享，也就是说在，owner不变的情况下，其他用户也能共享权限，共享之后，系统会在PrincipleObjecctAccess表记录某个用户对某实体具有什么权限；在我们查看记录的时候，系统还要运算一下，看某条记录有没有共享过给当前用户，这也是非常耗时的。

　　假设安全角色A对incidentt实体具有业务部门级别（2/4）的读取权限，给用户张三分配了安全角色A，并且某一条记录record1的owner是张三，那么张三所在部门的同样具有安全角色A的其他用户也具有读取record1的权限，因此，SystemUserBusinessUnitEntityMap表里面会保存除张三之外的其他用户的记录；当我们对张三的业务部门进行更换时，之前与张三同一个部门的其他用户则应该不能在查看该记录record1，那么系统会重新计算权限，计算哪些用户将会从SystemUserBusinessUnitEntityMap表中移除，而这个计算过程是非常缓慢的。

　　可以看出，影响SystemUserBusinessUnitEntityMap数据量的因素有：系统实体数量、用户数量、以及业务部门的层级设定（层级越少越好），还有就是安全角色中对某权限配置的权限层级。

1.系统实体数量。不难理解，实体越多，SystemUserBusinessUnitEntityMap表的记录则越多（经过调查发现，当实体的权限层级是0在SystemUserBusinessUnitEntityMap表中的记录数量与1/4时是一样的）。

2.用户数量。用户数量与系统实体数量一样。

3.业务部门的层级设定。层级越多，则减缓计算过程，影响记录分派的性能。

4.安全角色中对某权限配置的权限层级。一般来说权限层级越高，则在SystemUserBusinessUnitEntityMap表的记录越多，特别是3/4的深度级别；但组织级的权限不一样，也就是4/4的权限，该权限不会在SystemUserBusinessUnitEntityMap表存记录。

　　在我们知道了这些特点之后，我们就知道该如何更好的做设计，已达到性能最优，从下面几点考虑：

1. 用户数量、实体数量、业务部门这些会随着业务的增长可能会增多，但是业务部门的层级我们可以尽量扁平化；

2. 权限层级尽量不要设置为3/4，因为3/4的权限层级会在SystemUserBusinessUnitEntityMap表增加大量记录；

3. 记录的owner尽量不要设置为团队，可想而知，过多记录设置为团队的时候，将在SystemUserBusinessUnitEntityMap表存在大量记录，严重影响系统性能。

4. 尽量避免记录的共享操作，系统虽然有这样的功能，我们也可以尽量不用或少用，如有特殊情况不得不用的时候才用。当然为了减少共享带来的性能问题，我们也可以设定一定的规则来减少共享表PrincipleObjecctAccess，比如说，在关闭SR之后，和业务人员确认是否没有必要共享了，这时是可以撤销共享权限的，或者说三个月之后就没有必要在共享了，要查看也只能特殊账号查询，或数据归档后的历史数据查询。

5.对于停用的用户，考虑清理其安全角色。

6.对于停用的业务部门，考虑是否可以删除。

在实施过程中，确实遇到不少影响系统性能的设计：

1. 使用团队作为owner。
2. 业务部门层级过多。
3. 存在大量共享却没有撤销共享的机制。
4. 快速查找视图过多查找字段。
5. 工作台聚合视图过多，计算量大。
6. 滥用活动实体，所有的活动实体的记录会同时在ActivityPointerointer实体中存在一条记录。操作活动实体是非常糟糕的。
7. 查找字段所使用的视图使用了默认视图，该视图的数据范围过大。
8. 存在大量的工作流，且后台任务程序有触发工作流的代码而且非常频繁，工作流应尽量使用后台任务处理程序代替。
9. 代码所用的查询语句没有索引。
10. 数据不做归档处理。
11. 没有做负载均衡
12. 没有CDN，没有缓存机制
13.  etc.

以上所述Dynamics CRM的安全模型性能问题并不是说产品本身的缺陷，任何一个系统都会存在性能问题，就看我们怎么利用产品的特性来做出做好的效果，避免一些导致系统性能差的设计出现而缩短系统生命周期或增加运维成本。

如有不准确，欢迎指正分享，谢谢！