认识达内从这里开始

我们在上文中给大家简单分析了关于微服务编程开发在不同阶段的发展原则等内容，而在本文中我们会给大家分享一下在不同环境下的微服务架构框架的使用。

服务拆分与聚合

前提：服务拆分与聚合本篇文章中暂时不考虑web的微服务化设计，只说明后端服务的拆分与聚合实践。

服务拆分与聚合需要遵循的原则：服务一定是围绕业务的。但事实情况是在现在追求“开源整合”的背景下，纯粹的业务单元在不借助三方工具的前提下，需要消耗巨大的代价才能实现业务需求，同时也出现不同业务单元对同一个工具的强依赖性。因此在服务拆分与聚合时，我们考虑了两种形态的实现方式：业务支撑和工具支撑。

业务支撑

业务支撑需要考虑的是业务服务对象，业务内部逻辑。业务服务对象作为整个业务单元的对外形态，通过命名能够清晰的表达其涵盖的业务范围;业务内部逻辑需要对业务单元进行细粒度的拆分，类似一个实体类可以包括多个其他相关联的实体对象(当然如果服务拆分的足够细化，也可以把内部逻辑作为独立的业务单元，但是这样会加重业务直接的通信负载)。基于业务内部逻辑构建业务服务对象的真实场景。具体的拆分细节可以依赖DDD的实践方法进行(当然也需要根据业务做相应调整，没有普世之道)。

工具支撑

工具支撑需要结合业务考虑，分为两种：通用性工具和专用性工具。通用性工具旨在为所有业务单元运行提供统一的支撑平台，从而减少由于工具维护花费的精力，使得业务开发人员聚焦业务实现，一般通用工具包包括统一日志处理，统一拦截处理，返回数据统一封装，异常统一处理等等;专用性工具聚焦某个具体的业务单元，由业务单元自身维护(例如迭代升级)。工具支撑层面不会提供对外restful或者rpc的接口，对外的表现形式为编译好的依赖工具包(例如Github的管理接口的封装)。

服务架构选型

依照执行原则完成服务拆分以后，我们需要考虑的是合适的落地选型。选型方案要考虑的因素有很多：技术背景(尤其是团队内编程语言的设定)，服务支撑工具(注册中心，网关，服务调用，负载均衡数据库等)，服务运行工具(tomcat，jetty，jboss等)，服务部署工具(物理部署，虚拟化，容器等)，工具的协议支撑集合(http，rpc，mtqq，idoc等)。但是无论如何选型终一定要结合团队开发人员当下的技能支撑，这也是我们选型的核心因素，因为白盒相对来说始终比黑盒安全，也相对可控。这里给出我们的技术栈选型框架(仅限我们熟悉的内容)，暂时不涉及技术框架的对比说明。

服务开发框架：springboot，dubbo，grpc，ServiceMesh(基于ServiceMesh的开发服务框架)

分布式存储/注册中心：Zookeeper，Consul，Eureka，Etcd

服务网关：Kong，Openresty，SpringcloudZuul，Springcloudgateway

负载均衡：nginx，springcloudRibbon，haproxy，Kubernetesservice

服务远程调用：Springcloudfeign

缓存服务：memchace，redis

数据库：mariadb，mysql

消息服务：RabbitMQ，NATS，Kafka

配置中心：springcloudconfig，Apollo，Consul

事件机制：CloudEvent

服务编排：Conductor，Kubernetes

服务治理：springcloud，Dubbo，ServiceMesh

基于消息机制的分布式事务处理(遵循CAP或者BASE理论模型的实现)

业务运行工具：jvm，nginx或者其他可运行环境支撑

开发编译工具：Jenkins，maven，gitlab

接口文档：Swagger

部署工具：物理部署(jar包或者可运行的编译的二进制文件)虚拟化部署(虚拟镜像模板)容器化部署(Docker)

我们在落地的过程中，根据团队技术特点开发阶段重点选择了Springcloud中涵盖的技术栈。方便易用，能够快速入手。运行阶段选择具备服务编排能力的Kubernetes容器化运行环境。并且结合Devops工具链能够快速迭代部署。

服务接口设计

服务接口是对外展现业务逻辑的入口，接口定义的规范与否也是微服务落地的关键指标之一，我们在实践的过程中参考了多个开源项目的接口设计，针对任何一个资源对象，整体分为几类场景：资源集合类操作，资源实体操作，异常处理，参数处理，统一数据返回，审计日志以及其他具体场景。

统一的接口请求与响应标准

其中业务单元绝大多数端口围绕着资源集合类，资源实体类进行操作，因此我们从restful接口规范出发，结合具体场景，规范了请求方式，请求url，请求参数，请求header，响应header，响应值等信息。

请求参数涵盖默认语义，包括：Get(获取信息)，Post(创建)，Put(全量修改)，Patch(部分修改)，Delete(删除)

以Students实体对象的新建为例，给出请求与响应标准。

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