接下来，就是把微智能思想和拟社会化分布式设计统一起来，构建微服务计算平台的计算节点抽象模型。它遵循以下原则：
服务能力是实现业务逻辑的唯一方式，每种能力只包含一种业务逻辑
服务能力的实现方式遵守同一套技术实现框架，只有业务逻辑的差别，而运行机制，运维机制完全相同
每个计算节点是对等的，只有计算资源占用的差别，而运行机制，运维机制等完全相同
计算节点的分工由服务能力决定，部署的计算节点至少包含一种服务能力
计算节点的实现遵守同一套技术实现框架，且这套实现框架提供运行服务能力的容器
计算节点集群的构建方式是自动发现的，集群元数据的维护是由计算节点集群自我维护的
服务能力的发现方式是自动发现的，服务调用元数据的维护是由计算节点集群自我维护的
服务调用过程应具备自适应能力，尽最大可能保证服务调用通畅，在面对风险时，能够有一定的自主处理能力
允许服务能力的集成与编排，服务编排后的运行过程具备应对异常或风险的自适应性。
计算节点抽象模型：
服务能力是一种计算能力，分为基础服务能力和业务服务能力。
基础服务能力是构建计算平台的前提，也提供了对计算平台服务调用，监控，运维的支持。基础服务能力实际上是整个计算平台的基石，会在以后的分享专题中逐个展开说明。
业务服务能力是根据实际业务需求实现的服务能力
按照以上原则，服务计算节点还提供了三类基础支持：
服务能力的生命周期管理：
值得注意的是，服务能力可以被装配或卸载，这个过程分为Soft模式和Hard模式。Soft模式是通过配置的方式，服务能力的实现(例如jar包)还存在;Hard模式就是配置与实现一起装配或卸载。实际应用中，Soft模式更加灵活，服务能力实现的变更可以交给节点升级来做。
服务能力实现框架： 为实现业务逻辑提供一套统一的编程和运行框架。
组件化管理支持： 服务能力在业务层面是原子，但在实现层面可以分解为组件，组件是具备特定逻辑又具备通用逻辑的代码。
常用的编程组件的支持： 保持统一的，标准的技术栈，也加速服务能力的开发。一般包括：定时任务，HTTP服务端，HTTP客户端，内存队列异步处理，多线程或并行编程支持。当然通讯层面是根据实际选型来定，我们以HTTP作为标准通信。
计算节点自身管理： 为了实际运行和运维需要而提供的支持。
元数据管理： 比如每个计算节点需要一个唯一的ID来标识自己(就像人的身份证)，通过它第一次运行来创建，且持久化起来以便再次运行时能够保持ID不变;有些服务能力运行是会产生临时文件，这就需要计算节点提供一个“场所”(临时目录)供其施展。
节点自动升级/回滚： 这个是所有分布式系统中最重要的特性之一，它能大大提升变更大规模节点的效率，在微服务架构下尤其适合。这个变更过程包含两个方面：计算节点配置以及实现的变更，服务能力配置以及实现的变更。
节点的配置管理： 负责提供实际的配置读取/改写接口，以及将自身和服务能力的运行时的配置持久化等。
当然计算节点自身管理包含工作有很多扩展，要根据实际需求定义。
’
三、打造微服务计算的基础三件事
微服务计算平台实现服务治理首先要解决三个基础：服务注册与发现，服务监控，服务调用控制。
1
服务注册与发现
1 )服务注册
经典的服务注册方法有以下两种：
显式配置： 人工将服务的接口信息(服务名，服务URI等)配置到服务注册中心。WebService UDDI就是这种模式。它的问题是需要人工收集服务接口信息，这个过程可能产生滞后或者错误的信息，运维代价大。
代码实现： 调用服务注册中心客户端发送服务的接口信息到服务注册中心。典型用例是基于Zookeeper服务注册。它的优势是服务接口的URI可能是通过代码收集出来的，较人工收集更加自动化。