传统软件架构与微服务架构
使用一套小服务来开发单个应用的方式,每个服务运行在独立的进程里,一般采用轻量级的通讯机制互联,并且他们可以通过采用自动化的方式部署。
一、软件架构是什么
软件架构是在软件的内部,经过综合各种因素的考量、权衡,选择特定的技术,将系统划分成不同的部分并使这些部分相互分工,彼此写作,为用户提供需要的价值。
二、考虑的因素有哪些?
1、业务需求
2、成本
3、技术栈
4、组织架构
5、可扩展性
6、可维护性
三、单体架构
定义:功能、业务集中在一个发布包里,部署运行在同一个进程中。
四、单体架构的优势
1、易于开发,很容易理解
2、易于测试
3、易于部署
4、易于水平伸缩
五、单体架构面临的挑战
1、代码膨胀,难以维护
2、构建、部署成本大
3、新人上手困难
4、创新困难
5、可扩展性差
六、什么是微服务
使用一套小服务来开发单个应用的方式,每个服务运行在独立的进程里,一般采用轻量级的通讯机制互联,并且他们可以通过采用自动化的方式部署。
微服务特征
1、单一职责,只把相关的机制放在一起,跟这个业务不在紧密的可以分出去
2、轻量级通信,与平台无关、语言无关的通信机制,如protobuf
3、隔离性
4、有自己独立的数据存储系统
5、微服务可以由开发人员选择最适合自己的语言(技术多样性)只需要提供相应的api
微服务诞生背景
1、互联网行业的快速发展
2、敏捷开发、精益开发
3、容器技术的成熟,docker有效解决了微服务数量的庞大。
微服务的架构图(熟悉微服务)
假定业务场景:
1、一个在线教育网站的部分功能
2、用户可以登录注册、获取用户信息
3、由发送邮件发送短信功能
3、可以查看课程列表
微服务架构优势
1、每个服务都是相互独立的,可以根据qps的多少,来启动多少个微服务,扩缩容相对容易、都有自己独立的数据库。
2、技术栈灵活。每个微服务只需要保证自己的api接口
3、高效团队,团队需要的非常少。
微服务架构不足
1、需要对原有的系统进行微服务划分
2、数据一致性、微服务的数据库不同。
3、沟通成本,如果api改变,如果想修改就需要别的团队联合修改
微服务间如何通讯
一对一 | 一对多 | |
同步 | 请求响应模式,最常见 | ------- |
异步 | 通知/请求异步响应 | 发布订阅/发布异步响应 |
从通讯协议角度考虑
1、REST api 在网络中客户端和服务端进行通讯的一种格式
2、RPC dubbo\dubbox\motan\grpc\thrift
3、MQ 消息队列
RPC 微服务之间通信大部分都是这种
如何选择RPC框架?
1、I/O、线程调度模型(看是否单线程、多线程)
2、序列化方式(json\xml 可见)(protobuf 不可见)
3、多语言支持 (看业务是否跨度高)
4、服务治理(看是否有服务的监控等,一般有服务治理的框架,可以方便集群部署)
更多推荐
所有评论(0)