微服务与 DevOps实践：技术架构与组织架构 | IDCF
DevOps
共 7610字，需浏览 16分钟
·
2021-04-06 17:30
一、概述
从设计原则上来讲，微服务架构遵循 SOA 的设计原则。 小的、可重用的服务并不一定是微服务，微服务架构强调敏捷、独立开发、独立部署、独立扩展，重用在某种程度上会影响敏捷性。
敏捷性：微服务不仅可以提高开发的敏捷性，还可以加速持续部署（CD），从而使开发团队能够尽快部署新的功能。 减少风险：由于每个微服务都是比较小巧并且独立部署的，因此可以减少每次部署的风险。 适合分布式开发：微服务之间依赖程度低，因此可以更加灵活地独立开发。 技术灵活性：微服务之间的耦合程度低，因此技术团队可以根据不同的特点选择最合适的技术栈，例如利用不同的编程语言解决不同的领域问题。 可扩展性：一个应用有许多微服务组成，每个微服务可以根据需要独立扩展，而无须对整个应用做整体扩展。
Bounded Context Context Map Event Sourcing CQRS BASE
现有软件架构是否已经服务化或者按照系统功能做了模块化切分。 团队的敏捷成熟度如何，是否有足够的 DevOps 经验。 开发团队是否有足够的架构设计能力来适应采用微服务所带来的设计方法、模式以及技术架构上的巨大差异。 DBA 团队是否有能力和意愿制定新的数据管理模式——将数据管理的方式由原来的集中管理转变为去中心化管理。 运维团队是否有足够的能力为微服务提供全新的环境管理工具、部署工具和监控工具。
从单体应用或者传统分层架构的应用向服务化过渡，通过封装和组合等方式提供对外发布接口的能力，从而提升应用的可访问性。 通过重构将 Domain-Level（领域层面）的功能模块转变为可以独立部署的服务，从而提升整个应用的敏捷性。我们将这种可独立部署的服务称为 MiniService，其粒度比微服务粗，因而抽象难度比较低，但是也能在一定程度上获得微服务所带来的敏捷性提升的好处，但是对 DevOps 的基础设施等要求没有微服务高，因此建议没有微服务经验的团队可以从 MiniService 开始尝试。 通过 Feature-Level（特性层面）的抽象，根据单一职责原则将 MiniService 拆分成微服务，从而获得更高的扩展性和敏捷性。
二、融数数据微服务的架构选型
方便开发 方便迁移 多协议支持 多语言支持 方便监控 方便运维
Zuul 提供的 Edge Service 及 API 网关是完全基于 HTTP 协议的过滤器实现的，基于 HTTP 协议的同步调用方式会带来性能的损失，并且缺乏长连接的推送及多路复用的能力。 Zuul 不能满足 RPC 调用的需求，而在大规模团队协作的过程中，契约优先的开发方式优于代码优先的开发方式，因此对于应用内部交互来讲，RPC 框架从管理和协作的角度要优于 REST 服务。
基于对 gRPC 的封装，构建 Service Provider 的全新实现，替代 REST 服务。 通过 Proxy 方式，实现 gRPC 与 REST 服务的相互转换，保持系统兼容性。 进行去中心化治理，通过 Proxy 来实现端点治理，将客户端治理变为服务端治理。 通过扩展并集成 Zipkin 实现服务链路监控和运行时拓扑收集。 构建 Endpoint inventory 服务，以 semantic versioning 的方式管理服务版本。 将 Proxy 作为服务部署的执行端点，通过 VIP 绑定，透明化客户端寻址工作。利用 Proxy 提供轻量级的负载均衡、流量控制及灰度发布的功能。
三、设计思想
面向运维的设计，配合 DevOps 平台，提供服务生命周期管理及易于被监控的能力。 面向开发者，合理封装。开发者无须了解 gRPC 的具体实现。 基于 IDL 的契约优先的开发方式。 提供完善的测试框架和 Mock 工具。 提供完善的易于监控的能力。
四、总体架构
Graeae 架构与协议无关。该架构可以基于 Netty4、线程模型及 buffer pool 进行调整，以减少 GC 压力并通过线程切换提升性能协议。 遵循 protocol buffer 协议，可以做到通用性强、序列化性能好、压缩效率高。 语言中立，目前整个架构支持 Java、Python 和 Go 三种语言的开发。 引入了熔断器机制、流量控制、服务治理。 基于 Proxy 和 PaaS 平台进行分布式治理监控。 使用集成 Zipkin 的调用链监控，以及基于 Pinpoint 的 APM 监控。 对于该架构而言，直接调用的性能好于反射调用，且使用 Netty4 线程模型优化。
//服务提供方
public class SmsTemplateApplication {
public static void main(String[] args) {
new SpringApplicationBuilder().sources(SmsTemplateApplication.class)
.web(false).showBanner(false).run(args);
}
}
//服务实现
public class SmsTempletServiceImpl implements SmsTemplateService { @Autowired
private SmsTempletDao smsTempletDao;
@Transactional
public DeleteReply deleteById(IdRequest req) { return SmsTemplateReply.newBuilder().build(); }
}
主版本号：当做了不兼容的 API 修改时，需要递增主版本号。 次版本号：当做了向下兼容的功能性新增时，需要递增次版本号。修订号：当做了向下兼容的问题修正时，需要递增修订号。
五、对微服务的支撑
抽象了部署的最小单元——包。 每个微服务都是由包及其配置组成的，前面提到，服务框架做了代码和配置分离，因此这里可以将包和包的配置分离，提供运维便利性。 逻辑环境包括了微服务、微服务配置及运行微服务所依赖的 Host 或者 Host Group。 版本化逻辑环境，方便回滚。
六、DevOps 平台总体架构
七、融数数据面向微服务的研发团队介绍
八、总结
来源：技术琐话，内容选自《架构宝典》 作者：王东 王东，曾任融数数据北京研发中心 CTO，负责微服务、DevOps 以及大数据平台的研发和管理工作。曾供职于 IBM、普元、Amazon、OneAPM 等国内外知名公司。拥有 15 年以上的 JavaEE 编程和架构设计经验，精通 DevOps 和微服务，曾领导设计和开发普元 ESB 产品。熟悉支付相关的业务流程以及各个银行和支付机构的业务处理模式，熟悉应用与支付领域的大规模分布式系统设计和开发方法，熟悉电子商务行业的业务模型。专注于客户行为分析、营销、产品和服务、客户关系、线上销售、物流配送、渠道整合、供应链集成、售后服务、预测和推荐等各个电子商务主要环节的分析和设计，以及 IT 系统的规划和实施。精通 DDD、Scrum 等软方开发和设计方法论。
评论