认识达内从这里开始

微服务架构开发随着互联网的不断发展而被越来越多的企业应用到不同的软件开发项目之中，而本文我们就简单来了解一下，微服务架构开发原则都有哪些。

我们遵循的原则

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

初期阶段

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

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

实践阶段

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

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

协议标准

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

框架标准

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

接口标准

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

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

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。