🌡️

微服务概览

 
微服务概念
单体架构—化繁为简,分而治之
微服务起源:小即是美,单一职责,尽可能早的创建原型(提供api),可移植性比效率重要
微服务定义:原子服务、独立进程、隔离部署、去中心化服务治理
缺点:基础设施的建设、复杂度高
微服务也不是万能的:
1、分布式系统、固有的复杂性,可能需要使用rpc或者消息传递来实现进程间的通信;此外需要代码解决消息传递慢或者服务不可用等局部失效的问题
2、分区的数据库架构,同时更新多个业务主体的事务很普遍。单体架构往往只有一个数据库,在微服务架构里,多个服务使用多个数据库,对开发者要求更高
3、测试一个基于微服务架构的应用也比较复杂
4、服务模块的依赖,应用升级可能会波及多个服务模块的修改
5、对运维基础设施的调整比较大
 
服务组件化:
传统实现组件的方式是库和应用一起运行在进程中,库的局部变化意味着整个应用的重新部署
拆分后,单一服务的变化只需重新部署对应服务进程
用go实施一个微服务:
kit:一个微服务基础库(框架)
service:业务代码+kit依赖+第三方组成的业务微服务
RPC+message queue :轻量级通讯
本质上等同于多个微服务组合完成了一个完整的用户场景
 
按业务组织服务:
服务提供的能力和业务功能对应
一些不真实存在的,技术抽象的服务不应该存在微服务中
我们的模式:大前端(移动/Web) > 网关接入 > 业务服务 > 平台服务 > 基础设施(PaaS/Saas)
开发团队对软件在生产环境的运行负全部责任!
 
去中心化:
每个服务的场景不同,可针对性选择技术栈,但要避免过度多样化
数据去中心化
治理去中心化
技术去中心化
每个服务独享自身的数据存储设施(缓存,数据库等),不像传统应用共享一个缓存和数据库,这样有利于服务的独立性,隔离相关干扰。
 
基础设施自动化:
自动化测试和部署
单一进程的拆分为多进程,意味着开发、联调、测试、部署、监控的复杂度相应增大
必需要有合适的自动化设施来支持,否则开发、运维成本加大
cicd
自动化测试
在线运行时
 
可用性&兼容性设计:
著名的 Design For Failure 思想,微服务架构采用粗粒度的进程间通信,引入了额外的复杂性和需要处理的新问题,如网络延迟、消息格式、负载均衡和容错,忽略其中任何一点都属于对“分布式计算的误解”。
隔离
超时控制
负载保护
限流
降级
重试
负载均衡
 
一旦采用了微服务架构模式,那么在服务需要变更时我们要特别小心,服务提供者的变更可能引发服务消费者的兼容性破坏,时刻谨记保持服务契约(接口)的兼容性。
Be conservative in what you send, be liberal in what you accept.
发送时要保守,接收时要开放。按照伯斯塔尔法则的思想来设计和实现服务时,发送的数据要更保守,意味着最小化的传送必要的信息,接收时更开放意味着要最大限度的容忍冗余数据,保证兼容性。