共享服务体系搭建
去中心化分布式服务框架除了对于 SOA 特性的实现和满足外,相比中心化服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何 服务路由中介, 避免因为中心点带来平台能力难扩展问题,以及潜在的雪崩影响
关于雪崩
微服务架构的典型特征
按照业务划分也不是按照技术划分
做有生命的产品而不是项目
关于微服务的”微”
服务中心建设
服务中心一定是不断发展的
服务中心的多样性
服务中心可以进一步划分
服务中心划分原则
三个方面
四个原则
数据拆分
数据尽可能平均拆分(用户订单和子订单Hash方案)
尽可能减少事务边界
所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量,上面示例中就是事务边界大的典型示例,即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大,会给系统带来以下弊端:
异步化
业务流程异步化:MQ
数据库事务异步化:解决平台性能的核心问题
事务与柔性事务
BASE是指基本可用(BasicallyAvailable)、柔性状态(SoftState)、最终一致性(EventualConsistency)
“基本可用”是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。
ACID与BASE区别
数字化运营(异常追踪和定位)
在每个应用集群的运行环境中,每当应用中进行了远程服务调用、缓存、数据库访问等操作时,都会生成相关的访问日志并保存到应用所在的服务器上。
在每一个URL请求都会生成一个全局唯一的ID,鹰眼平台中称为TraceID,这个ID会出现在该请求中所有服务调用、数据库、缓存、消息服务访问时生成的所有日志中。
TraceID一般包含:
平台稳定性
限流和降级
压测
被压测的单机的关键指标(CPU利用率、系统整体负载、QPS、响应时间等)达到的阀值水位后即自动停止压测,以免对生产环境产生大的影响。
基础数据抽取:模拟尽可能真实
链路和模型:用户的行为不同,代表链路,参数,模型不同,需要综合考虑模拟真实行为
影子表:数据的隔离是全链路压测诞生阶段的一大难题。全链路压测的链路有读有写,并且在线上进行,为了不污染到线上的正常数据,全链路压测在同一个数据库的实例上对数据库表建同样结构的影子表来进行数据的隔离。
安全机制:全链路压测的安全机制分两层:第一层是安全的监控和保护,建立非法流量的监控机制,正常用户访问不了测试数据,测试账户也访问不了正常数据,防止数据错乱;并且设置压测引擎集群的白名单,防止恶意访问;第二层是对压测流量的安全过滤,针对压测流量放松安全策略,使得压测流量不被判别为攻击流量。
服务化野蛮生长面临的问题
服务的数量和业务覆盖越来越大
应用和业务架构越分越细,服务越来越专业化,跨领域理解的成本越来越高
服务安全控制层缺乏
开发体验不友好,产品接入时,开发使用手册,文档建设差
整体服务缺乏一个统一的服务治理层