完全独立的部署结构： 每个服务实例都能独立部署
服务能力可以编排： 不同的服务实例之间需要协作才能完成“更大”的业务
更多同类型实例： 业务种类决定了服务种类，而业务负载的大小决定了某种服务类型的实例数量，当然这可能也意味着更加稳定的服务输出。
这里引入一个很有意思的思考：社会是由人(个体)构成的相互协作的群体，每个人都可能具备几种技能，并使用这些技能参与到社会分工协作中去。具备同种技能的人可以一起协作来提高生产效率和提供可靠性高的生产输出;具备不同技能的人可以在某一件事情上进行分工协作，形成生产流水线。
其实可以发现微服务的特性跟人类社会的运作方式很像。服务实例就是个体，服务能力就是技能，允许服务实例具备几种服务能力，具备相同服务能力的实例可以看做同类型的实例，多个同类型实例构成的集群可以实现负载均衡和高可用，不同类型实例可以被编排在一起完成业务流程。我们把这种分布式设计称为“拟社会化”。
“拟社会化”分布式设计抽象图：
“拟社会化”分布式设计的特点：
服务计算节点与服务能力之间没有必然联系， 这是与传统分布式设计的重要区别。 服务计算节点是运行资源的载体，服务能力是业务逻辑的载体。
服务计算节点允许多个服务能力。
服务能力有两种状态：激活(可以使用)，非激活(存在但不可用)。
服务能力是独立的，可装配的。
服务集群实际是服务能力的集群， 这也是区别传统单体架构集群或SOA服务集群的关键。
服务的协作过程实际是服务能力的协作过程，而不是服务计算节点的协作过程。
由于协作过程因为服务能力的可变性，使得可以动态定义服务能力集群，即软件定义服务集群(SDSC)。
这里可能有个疑问：为什么允许某个服务计算节点有多个服务能力，这是不是一种“倒退”，不符合微服务的原则?其实主要有两个方面的原因：
资源使用方面： 在实际实施过程中，难以保证每个服务能力都能独享服务计算节点，而且事实上如此实施会过于极端了。微服务的服务实例数量会比传统架构的增长几倍甚至几十倍，难以依靠单纯增加资源投入的方式来满足部署需求。
服务编排的需要： 这是更重要的一点，服务输出是体现在服务能力上(再次强调不是服务计算节点)，这也是“微”的体现。由于服务能力可以激活也可以“休眠”，那么某个复合能力节点就具备了服务能力输出的多样可能性。比如某个服务计算节点可能在一段时间属于某个服务能力集群，在另一段时间属于另外一个服务能力集群，通过这种方式实现计算资源的最大化利用。
这里举两个例子对“拟社会化”分布式设计的应用加以说明。
实践实例一： 短信系统是常见的高并发系统，在互联网环境下可能因为各种营销活动引起Peaktime，常规的做法是增加资源，但现实是资源池是有限的，而且多数时候Peaktime会波及整个营销活动链条的系统，这些系统都需要增加资源，很快资源池就分光了。在“拟社会化”的分布式设计下，可以通过服务能力的快速切换，把一些业务休眠或在当前时间段体量小的服务能力的计算资源向Peaktime的服务能力集中，在Peaktime过去以后，又能快速的恢复原集群。同时，可以发现另一个特性的体现：软件定义集群。这个特性会在以后的分享专题中专门说明。
实践实例二： 在P2P业务中，线下签约通常是白天进行而晚上无业务，而签约数据的统计工作是T+1的模式，是在晚上进行。传统方式是部署两个完全独立的系统，而“拟社会化”的分布式系统通过复合能力节点，以服务能力切换的方式实现同一套计算资源的复用。
3
计算节点抽象模型