微服务落地，我们在考虑什么？
|
副标题[/!--empirenews.page--]
导读：微服务已经成为过去几年软件架构设计的“事实标准”，大多数企业在推动内部数字化转型的过程中，服务软件系统开始由单一或者SOA服务向微服务转型。那么转型过程需要遵循哪些原则呢?本文结合过往博云微服务落地实践经验，分享微服务落地实践的过程中思考。
目前当技术人员提及微服务的时候，首先想到的是Spring Cloud、Dubbo等实现服务的技术框架。这在我们采用微服务的初期阶段是最先考虑的因素。可是随着服务化的进行，我们并没有享受到由框架的便利性与快捷性所带来的业务突飞猛进的成就感。恰恰相反，过多的服务化以及服务间冗余且多元化通信机制反而加重了业务处理的负担。这必然不是我们想要的微服务，却是大多数企业在执行的微服务。 因此我们开始重新审视整个行业，审视微服务的发展历程。与过往不同的是：前期阶段，我们把更多的精力投入到业务上，而一定程度上“忽略”技术，因为此时我们建立的信念是无论何种形式的“服务形态”一定是为业务服务的。 当我们站在全局的角度，观看整理后的服务，发现了一个及其优美的图形化结构，各个节点的边界清晰，职责分明;节点间的链路畅通，协议规整。这时我们知道我们终于走在了正确的道路上。 我们遵循的原则 当经过一定时间的挣扎以后，我们觉得微服务的关注点不在于技术本身，但并不意味着不关注技术。在反思过程中，我们认为微服务实践中有两个原则不能变：服务一定是围绕业务的，服务的交互是标准的。我们把原则分为两个阶段：初期阶段，实践阶段。 初期阶段 初期阶段，遵循第一条原则，服务一定是围绕业务的。微服务初期阶段，重要的是业务梳理，而不是花费大量时间在RPC、Service Discovery、 Circuit Breaker这些概念或者Eureka，Docker，Gateway，Dubbo等技术框架的调研上，此时我们重心关注服务的边界与职责划分。 这是遵循的两条原则：
这样的原则下，DDD为我们提供了帮助，也依据业务本身的特性实现了服务初期阶段的整理。同时我们发现就算借助DDD的指导，在不同的业务应用中，各个服务也有不同的聚合形态和调用方式。因此我们觉得微服务本身没有一成不变的模式，一切都是围绕业务动态变化的。合理性也仅仅体现在一定阶段的时间范围之内。 实践阶段 当业务建模完成，我们能够清晰的知道各个业务的职责以及与其他业务的关联关系，从理论层面我们完成了业务微服务建模。此时我们开始着手服务的落地实践，在落地实践阶段我们更多关注点同样不在于技术框架，而是在于技术框架的内涵-即服务交互标准。 此时我们遵循了第二条原则：服务的交互是标准的。所谓服务交互标准从三个层面解读：协议标准，框架标准，接口标准。 协议标准 目前网络应用的协议比较复杂，我们希望选取能够符合业务场景的协议作为通信标准。因此我们考虑了统一的认证鉴权协议、加密解密协议、内部接口交互协议，外围接口服务协议等，各个协议各司其职，用来支撑服务通信的标准化。协议标准不仅仅为平台自身服务，同时与其他业务单元进行通信时，只需要遵循协议标准，就可以实现业务单元之间的快速联动。 框架标准 为了支撑业务，我们没有依赖任何的自动化代码生成框架，而是根据我们的协议支持情况，选择最小的服务运行框架，来构建统一的业务单元支撑框架。这里需要说明的一点，框架标准需要考虑业务特性，协议特性，不能一概而论，因此它的有效性也许只在当前构建的业务平台本身。构建标准框架的好处是针对应用内的所有业务单元可以快速复制，简化因为各自开发框架不同导致联调阶段出现问题。 接口标准 接口分两种：业务内部接口和业务服务接口。无论哪种接口同样遵循标准化原则。 业务内部接口的核心在于压缩协议，加快业务的处理流程，因此可以采用RPC等高效率的协议支持的接口模式;业务服务接口的核心在于表明业务携带的信息，因此采用restful接口规范更合适一些。接口设计需要涵盖但不限于标准化的请求方式、统一的参数处理、统一的结果返回、统一的异常处理、统一的日志处理等。 服务拆分与聚合 前提：服务拆分与聚合在本篇文章中暂时不考虑web的微服务化设计，只说明后端服务的拆分与聚合实践。 服务拆分与聚合需要遵循的原则：服务一定是围绕业务的。但事实情况是，在现在追求“开源整合”的背景下，纯粹的业务单元在不借助第三方工具的前提下，需要消耗巨大的代价才能实现业务需求，同时也出现不同业务单元对同一个工具的强依赖性。因此在服务拆分与聚合时，我们考虑了两种形态的实现方式：业务支撑与工具支撑。 业务支撑 业务支撑需要考虑的是业务服务对象和业务内部逻辑。业务服务对象作为整个业务单元的对外形态，通过命名能够清晰的表达其涵盖的业务范围;业务内部逻辑需要对业务单元进行细粒度的拆分，类似一个实体类可以包括多个其他相关联的实体对象(当然如果服务拆分的足够细化，也可以把内部逻辑作为独立的业务单元，但是这样会加重业务直接的通信负载)。基于业务内部逻辑构建业务服务对象的真实场景。具体的拆分细节可以依赖DDD的实践方法进行(当然也需要根据业务做相应调整，没有普世之道)。 工具支撑 工具支撑需要结合业务考虑，分为两种：通用性工具和专用性工具。通用性工具旨在为所有业务单元运行提供统一的支撑平台，从而减少由于工具维护花费的精力，使得业务开发人员聚焦业务实现，一般通用工具包包括统一日志处理，统一拦截处理，返回数据统一封装，异常统一处理等等;专用性工具聚焦某个具体的业务单元，由业务单元自身维护(例如迭代升级)。工具支撑层面不会提供对外restful或者rpc的接口，对外的表现形式为编译好的依赖工具包(例如Github的管理接口的封装)。 服务架构选型 （编辑：西双版纳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
