认识达内从这里开始

微服务编程开发随着软件开发行业的不断发展变化而得到广大程序员的认同，下面我们就一起来简单了解一下，关于微服务架构在不同阶段的一些原则都有哪些。

我们遵循的原则

当经过一定时间的挣扎以后，我们觉得微服务的关注点不在于技术本身，但并不意味着不关注技术。在反思过程中，我们认为微服务实践中有两个原则不能变：服务一定是围绕业务的，服务的交互是标准的。我们把原则分为两个阶段：初期阶段和实践阶段。

初期阶段

初期阶段，遵循一条原则，服务一定是围绕业务的。微服务初期阶段，重要的是业务梳理，而不是花费大量时间在RPC、ServiceDiscovery、CircuitBreaker这些概念或者Eureka，Docker，Gateway，Dubbo等技术框架的调研上。此时我们重心关注服务的边界与职责划分。

这是遵循的两条原则：

(1)保证单一业务服务高效聚合;

(2)降低服务间的相互调用(此举是避免陷入大量分布式业务的处理)。这样的原则下，DDD为我们提供了帮助，但也依据业务本身的特性实现了服务初期阶段的整理。同时我们发现就算借助DDD的指导，在不同的业务应用中，各个服务也有不同的聚合形态和调用方式。因此我们觉得微服务本身没有一成不变的模式，一切都是围绕业务动态变化的。合理性也仅仅体现在一点阶段的时间范围之内。

实践阶段

当业务建模完成，我们能够清晰的指导各个业务的职责以及与其他业务的关联关系，从理论层面我们完成了业务微服务建模。此时我们开始着手服务的落地实践，在落地实践阶段我们更多关注点同样不在于技术框架，而是在于技术框架的内涵——即服务交互标准。

此时我们遵循了二条原则：服务的交互是标准的。所谓服务交互标准从三个层面解读：协议标准、框架标准、接口标准。

协议标准

目前网络应用的协议也比较复杂，因此我们希望选取能够符合业务场景的协议作为通信标准。因此我们考虑了统一的认证鉴权协议，加密解密协议，内部接口交互协议，外围接口服务协议等，各个协议各司其职，用来支撑服务通信的标准化。协议标准不仅仅为平台自身服务，同时与其他业务单元进行通信时，只需要遵循协议标准，就可以实现业务单元之间的快速联动。

框架标准

为了支撑业务，我们没有依赖任何的自动化代码生成框架，而是根据我们的协议支持情况，选择小的服务运行框架，来构建统一的业务单元支撑框架。这里需要说明的一点，框架标准需要考虑业务特性，协议特性，不能一概而论，因此它的有效性也许只在当前构建的业务平台本身。构建标准框架的好处是针对应用内的所有业务单元可以快速复制，简化因为各自开发框架不同导致联调阶段出现问题。

接口标准

接口分两种：业务内部接口，业务服务接口。无论哪种接口同样遵循标准化原则。

业务内部接口的核心在于压缩协议，加快业务的处理流程，因此可以采用rpc等高效率的协议支持的接口模式;业务服务接口的核心在于表明业务携带的信息，因此采用restful接口规范更合适一些。接口设计需要涵盖但不限于标准化的请求方式，统一的参数处理，统一的结果返回，统一的异常处理，统一的日志处理等。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。