如何具体实践微服务

如何具体实践微服务

微服务框架选型

选型准侧

  • 生产级:我们选择的技术栈是要解决实际业务问题和上生产抗流量的(选择不慎可能造成生产级事故),而不是简单做个 POC 或者 Demo 展示,所以生产级(Production Ready),可运维(Ops Ready),可治理,成熟稳定的技术才是我们的首选。
  • 一线互联网公司落地产品:我们会尽量采用在一线互联网公司落地并且开源的,且在社区内形成良好口碑的产品,它们已经在这些公司经过流量冲击,坑已经基本被填平,且被社区接受形成一个良好的社区生态。
  • 开源社区活跃度:GitHub 上的 stars 的数量是一个重要指标,同时会参考其代码和文档更新频率(尤其是近年),这些指标直接反应开源产品的社区活跃度或者说生命力。

服务框架是一个比较成熟的领域,有太多可选项。Spring Boot/Cloud,由于 Spring 社区的影响力和 Netflix 的背书,目前可以认为是构建 Java 微服务的一个社区标准。

Dubbo是阿里多年构建生产级分布式微服务的技术结晶,服务治理能力非常丰富,在国内技术社区具有很大影响力,Dubbo 本质上是一套基于 Java 的 RPC 框架,

新浪微博开源的 Motan,功能和 Dubbo 类似,可以认为是一个轻量裁剪版的 Dubbo。

gRPC是谷歌近年新推的一套 RPC 框架,基于 protobuf 的强契约编程模型,能自动生成各种语言客户端,且保证互操作。支持 HTTP2 是 gRPC 的一大亮点,通讯层性能比 HTTP 有很大改进。

服务拆分

微服务拆分过程中需严格遵守高内聚、低耦合原则,同时结合项目的实际情况,综合考虑业务领域、功能稳定性、应用性能、团队以及技术等因素。

1、基于业务领域拆分,在领域模型设计时需对齐限界上下⽂,围绕业务领域按职责单一性、功能完整性进行拆分,避免过度拆分造成跨微服务的频繁调用。

2、基于业务变化频率和业务关联拆分,识别系统中的业务需求变动较频繁的功能,考虑业务变更频率与相关度,并对其进行拆分,降低敏态业务功能对稳态业务功能的影响。

3、基于应用性能拆分,考虑系统⾮功能性需求,识别系统中性能压力较大的模块,并优先对其进行拆分,提升整体性能,缩小潜在性能瓶颈模块的影响范围。

4、基于组织架构和团队规模,提高团队沟通效率。

5、基于软件包大小,软件包过大,不利于微服务的弹性伸缩。

6、基于不同功能的技术和架构异构以及系统复杂度。

用DDD走出设计微服务拆分困境

所谓的微服务拆分困难,其实根本原因是不知道边界在什么地方。而使用DDD对业务分析的时候,首先会使用聚合这个概念把关联性强的业务概念划分在一个边界下,并限定聚合和聚合之间只能通过聚合根来访问,这是第一层边界。然后在聚合基础之上根据业务相关性,业务变化频率,组织结构等等约束条件来定义限界上下文,这是第二层边界。有了这两层边界作为约束和限制,微服务的边界也就清晰了,拆分微服务也就不再困难了。

微服务组件

注册中心

  • Eureka
  • Nacos
  • Zookeeper
  • Consul 服务调用
  • Rpc(thrift、gRPC)
  • Http (Feign、Ribbon) 服务监控
  • 调用链监控
  • Zipkin
  • Skywalking
  • Pinpoint
  • Cat
  • 日志监控
  • ELK
  • 健康检查和告警通知
    • Springboot-admin
    • Prometheus 服务网关
  • Gateway
  • Kong 服务安全
  • spring cloud security 配置中心
  • SpringCloud Config
  • Nacos
  • Apollo 服务容错
  • Hystrix
  • Sentinel 接口文档
  • Swagger 服务部署
  • 集群资源调度系统
    • kubernetes
    • mesos
  • 镜像治理
    • harbor
  • 构建平台
    • Jenkins

参考:

微服务架构技术栈选型手册

小程眼里的微服务

原文发布于微信公众号 - 分母为零(gmg1014)

原文发表时间:2019-08-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券