1架构总览
此架构支撑的业务是 一天10G的日志处理,100个左右的QPS
##业务流
Flume+elastic-search-----
放入DB中,缓存redis----ok
切换银行,接口升级-----ok
放入db中,缓存redis。
异步补偿,定时补偿,增加事务纪录表
接收外部的异步通知接口必须支持幂等
通过数据库唯一性约束保证。
走任务调度中心
一般来说是实时,如果业务处理速度跟不上,业务量大的功能10分钟补一次单,业务量小的1分钟补一次单
定时探针测试。-----测试环节
单体架构
SOA
微服务
一个归档包包含了应用所有功能的应用程序, 我们通常称之为单体应用。
架构单体应用的架构风格, 我们称之为单体架构, 这是一种比较传统的架构风格。
单体架构的缺点
复杂性逐渐变高
技术债务逐渐上升
部署速度逐渐变慢
阻碍技术创新
无法按需伸缩
面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。
##分布式系统优点
- 1:把模块拆分,使用接口通信,降低模块之间的耦合度.
- 2:把项目拆分成若干个子项目,不同的团队负责不同的子项目.
- 3:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
- 4:可以灵活的进行分布式部署.
- 5:提高代码的复用性,比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android,ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。
##分布式系统缺点
系统之间的交互要使用远程通信,接口开发增大工作量
微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统的。
其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。
这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。
这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。
对这些微服务我们仅做最低限度的集中管理
微服务特点:
1. 每个微服务可独立运行在自己的进程里;
2. 一系列独立运行的微服务共同构建起了整个系统;
3. 每个服务为独立的业务开发,一个微服务一般完成某个特定的功能,比如:订单管理、用户管理等;
4. 微服务之间通过一些轻量的通信机制进行通信,例如通过REST API或者RPC的方式进行调用。
微服务优点:
易于开发和维护
启动较快
局部修改容易部署
技术栈不受限
按需伸缩
DevOps
微服务挑战
运维要求较高
分布式的复杂性
接口调整成本高
重复劳动
微服务设计原则
单一职责原则
服务自治原则
轻量级通信原则
接口明确原则