01微服务概览

微服务起源

早期有一种面向服务的架构模式,也就是SOA–可以将微服务理解成轻量级SOA的一种最佳实践。

从单一的“全家桶”架构,其拥有单一的数据库,需要考虑非常清晰的模块划分以及依赖等等。通过化繁为简、分而治之,将原来“全家桶”架构演进到分布式的一个微服务的模型。不同的服务存在很强的隔离性和独立部署性。

特点:

  • 小即是美:小的服务代码量少,bug也会少,易于测试,也更容易不断迭代完善进而趋近完美。

  • 单一职责:一个服务也只需要做好一件事情,专注才能做得更好。----借鉴《代码整洁之道》

  • 尽可能早的定义接口原型:尽可能早的提供服务API,达成服务间的沟通一致性的约定,至于实现和完善可以后面慢慢再做,起先甚至可以做一些mock。

  • 可移植性高于效率重要性:服务间的轻量级交互在效率可移植性之间,首要考虑兼容性可移植性。—在不同的场景下需要选择不同的语言进行开发,若选择兼容性更强的框架,则不同语言之间进行交互会变得easy,否则维护将会变得更加复杂。

微服务定义

首先其需要围绕业务功能构建,服务只需要关注单一的业务,服务间采用轻量级的通信机制(此通讯机制应该是相互兼容的,各种语言都是可以打通的,如HTTP restful等,也易于实现),可以独立部署,以及能够使用不能的编程语言和存储方案。微服务架构通过业务拆分实现服务组件化(把一个服务当做组件来拆分),通过组件之间的组合来完成一个系统的开发(可理解为面向业务场景的一种API或功能),业务单一的服务组件又能够单独的部署,这样整个系统都会变得很灵活

优点

  • 原子服务

    意味着一个微服务关注的单一的业务场景和单一的业务。其API一定是围绕这个单一的业务单元来构建的。

  • 独立进程

    独立的进行部署和交互。

  • 隔离部署

    例如巨石部署的时候倾向于部署在一个强大的物理机上,假设3台48核,虽然能抗住流量需求,但是若出现一台机器宕机之后,影响的可能有1/3的服务,微服务流量小、业务单一,所以可以部署成一个4核,整体可能需要40台物理机(或者docker),那么若有一台宕机之后,对整个系统服务影响其实是没有太大的。

  • 去中心化服务治理

    服务与服务之间通信更简单,也就是说A服务直连B服务,节点之间也是RPC直连通信的。但是像服务发现等场景就需要一个集中化的服务发现组件。

缺点:

  • 对基础设施建设的高度依赖性。

    入力当从巨石应用变为多个小应用之后,应用管理的复杂度会变高,监控设施和体系 、日志查看。技术复杂度会变高、数据一致性的复杂度变高。

组件服务化

实现一个微服务需要组件服务化。

传统的组件通常是提供各种各样的代码库或者SDK,库和应用是一起运行在进程中的,一个库的局部变化会导致整个应用重新进行交付(指巨石架构的一个完整应用)。

在通过服务实现组件化之后,应用被拆分成一系列的服务运行在不同的进程中,单一服务的局部变化只需要重新部署对应的服务进程即可。

用Go实现一个微服务:

  • kit:一个微服务的基础库(框架)
  • service:业务代码+kit依赖+第三方依赖组成的业务微服务
  • RPC + message queue:轻量级通信

本质上等同于把多个微服务组合compose完成了一个完整的用户场景(usecase)

去中心化场景

每个服务面临的业务场景不同,可以针对性的选择合适的技术解决方案(可能存在多语言)。但是需要注意避免过度的多样化,需要结合实际场景来选择。否则每个服务都用不同语言的技术栈实现(则很难构建一个kit库/基础库、多套SDK),则维护成本就会大大变高。

  • 数据去中心化

    每个人独占实例、独占数据库、独占cache,一个超大数据库解决所有

  • 治理去中心化

    所有流量热点的地方,避免一个集中式的东西来处理、做分发或做流量处理

  • 技术去中心化

    不一定需要绑定到某一种语言,满足轻量级、兼容级

每个服务独自拥有自身的数据存储设施,不像传统应用共享一个缓存和数据库,从隔离性上考虑这个服务能够独立部署交互,并且其使用的资源也是隔离的,避免相互干扰

基础设施自动化

自动化包含测试、部署。

  • CICD
  • Testing:测试环境、单元测试、API自动化测试
  • 在线运行时:kubernets等

若有错误,请提出斧正。谢谢

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值