微服务
微服务
简介
微服务是软件开发中把一个单一的应用按业务功能分解成多个职责单一的“微小”服务的架构方法。
每一个服务都有其独特且定义良好的角色,有自己的进程,并利用轻量化机制(通常为 HTTP RESTful API)实现通信。
在同一应用中,每个微服务都围绕着具体业务进行构建,可以独立于同级其他的服务,进行部署、升级、扩展和重启。
它们通常由自动化系统进行编排,使得在不影响最终用户的情况下,对实时应用程序的频繁更新成为可能。
"微服务"强调的是服务的大小,关注的是某一个点。
"微服务架构"则是一种架构思想和模式,需要从整体上对软件系统进行通盘的考虑,提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。
换而言之,微服务架构就是将应用程序构建为一套服务。
每个服务都有各自的边界,都可以独立部署和扩展,可以采用不同的技术栈(不同的编程语言,不同的数据库等),可以由不同的小团队开发和维护。
在微服务架构下,每个服务的问题基本都可以在职能俱全的小团队内部得到快速解决,减少沟通和协调的成本。
这个团队应该从“产品的角度”,负责产品的整个生命周期,而不是但从“项目的角度”,交付完成后,就解散,从此各不相关。
一个持续产品生命周期的团队,时刻关注他们的产品状态,增加客户联系,同时承担一些售后支持,是能够帮助软件和客户提升业务能力的。
微服务类似乐高积木,可以拼在一起搭建一个标准模型。
首先,开发人员需要识别项目需要哪些单独的服务,例如搜索,认证,消息传递等。
然后,从开源到成套的企业解决方案之间做选择,最后把所有东西整合成一个应用。
换句话说,微服务使开发人员不必在已经解决的技术问题上再浪费时间,重复造轮子。
团队中的每个开发人员只需专注自己那部分工作,无需关注底层的基础架构。
如果在生产中,拼在一起的各个模块不能很好的工作,则很容易将它们隔离,拆开并重新配置
微服务可以在容器内运行,也可以作为完整的虚拟机运行。
也就是说,像Docker和Kubernetes这样基于容器的开源系统,是开发、部署和管理微服务的一种非常有效的方式。
围绕容器产生的众多成熟和强大的工具、平台及各种服务,使得容器化天生就适合微服务应用。
微服务架构也有缺点:
微服务的远程调用会比单一应用的进程内调用消耗更多的资源,而且在组织上也会更复杂,面临更多的挑战,但随着应用复杂度的提升,微服务架构的威力也会逐渐显现。
相对一体化的应用,需要一些额外的基础设施,例如部署流水线、监控(日志、指标收集)等
团队成员也需要实现或解决新的关注点:
- 微服务间的额外跳转导致网络延迟增加
- 低延迟身份认证和授权
- 独立部署和回滚
- 良好定义的接口:功能聚焦的同时,兼顾扩展
- 无状态的业务逻辑
- 依赖关系
- 工具和过程
- 。。。。。。
但随着应用复杂度的提升,经验的累积,这些挑战将变得越来越少,微服务架构的威力也会逐渐显现。
初见
其他
行动是绝望的解药!
欢迎转载和引用,但请在明显处保留原文链接和原作者信息!
本博客内容多为个人工作与学习的记录,少数内容来自于网络并略有修改,已尽力标明原文链接和转载说明。如有冒犯,即刻删除!
以所舍,求所得,有所获,方所成。