zoukankan      html  css  js  c++  java
  • 一、微服务架构

    在大型网站中,要面临的问题很多,但核心问题还是数据量、访问量快速膨胀带来的稳定性、性能、成本、效率的问题,此外就是和算法相关的问题。
    

    一、微服务的演进

    单体架构 -> 集群 -> 垂直化 -> SOA -> 微服务化

    1. 单体架构

    [IMG]
    引入问题: 单机支持的并发量有限,且会存在单点故障

    2. 集群

    随着并发量提升,一台tomcat支持300并发量,部署集群2台就可以支持600的并发,部署集群可以提升并发量,同时也避免了单点故障,提升了可用性。
    其中请求的分发需要负载均衡算法,且服务是无状态化的;
    [IMG]

    存在问题:随着业务复杂度提升,服务耦合严重。

    3. 垂直化

    一个产品随着用户越来越多,业务复杂度也随之越来越高,因为产品要满足各年龄段、不同兴趣爱好、地域等不同人群的需求,这些人群的需求体验都不一样;此时将这些业务放在同一个服务器内,耦合度就会越来越大,此时就可以按照不同业务维度来拆分。
    以电商为例,有用户、订单、商品服务;随着业务复杂度提升,可以将1个服务垂直拆分为3个业务模块,3个独立的业务数据库,部署在3个不同的容器,对外也有三个不同的子域名,通过单点登录来实现登陆一次;
    [IMG]

    存在问题: 当用户服务查询订单信息时,也需要维护订单的信息,而订单在订单服务内本身也存在,就会存在冗余代码,代码的耦合性提升;当订单结构有一些变化,上层依赖都需要做更改;为解决这个问题,引入了服务化的概念SOA

    4. SOA 面向服务的编程

    以某一种特定规范定义服务;在原3个服务层和3个数据库层之间加一套服务层; 特点是只提供一些公共的基础服务的接口;核心目标是通过服务的流程化提高业务的灵活性;主要解决数据的互联互通和业务的重用;
    [IMG]

    存在问题:当业务复杂度进一步提升,服务根据具体业务拆分为更细的模块来减少耦合

    5. SOA到微服务,强调服务的粒度

    微服务降低服务的耦合度; 用户有用户、账户、积分,此时可拆分为 用户服务、账户服务、积分服务; 订单服务可以拆分为 订单、交易、支付服务;
    当SOA细粒度之后,也就有了微服务化;微服务强调的是服务的解耦,更像是一种思想的提炼;(SOA 面向服务、微服务强调服务的粒度)多个微服务组成SOA服务;
    [IMG]
    微服务带来的问题:底层服务由10个变成100个,带来的底层系统资源、运维资源是否成熟,软件交付链路、底层基础化信息的演进,更加强调基础化运维的重要性(docker、k8s)

    微服务 SOA区别 :
    SOA 面向服务,核心目标是通过服务的流程化提高业务的灵活性;主要解决数据的互联互通和业务的重用,信息孤岛的问题;
    微服务强调服务的粒度,强调服务的解耦;

    二、分布式

    分布式架构
    两个特点:
    1.分布性 ,分布在不同的计算机节点上
    2.远程通信,来完成数据交换

    调用方   ->    提供方1、2、3..
     
    调用方要提前知道提供方的地址;这些地址维护在哪里;
    写死在调用方服务? 当提供者挂掉,怎么办
    服务上下线的动态感知 (上线:恢复和扩容;下线:宕机)
    
    1. 服务上下线的动态感知 
    2. 高效管理服务提供者的地址   (引入注册中心 zk、redis, 提供者注册,调用者访问,负载均衡放在调用方)
    	负载均衡算法:轮训、权重、hash、随机
     
    服务公共的配置的维护
    

    Spring Cloud

    Service Mesh

  • 相关阅读:
    eclipse下配置Spring环境
    筑梦路上的孤独行者
    Js继承各模式总结
    水题-poj1979
    C++静态数据成员存在的意义
    Mac_Sublime_JavaScript
    LeetCode204——count primes
    (吐槽)讨厌的VIP机制
    LeetCode55——Jump Game
    LeetCode62——Unique Paths
  • 原文地址:https://www.cnblogs.com/Qkxh320/p/MicroService.html
Copyright © 2011-2022 走看看