zoukankan      html  css  js  c++  java
  • 中台架构是什么

    一、该不该使用微服务架构

    根据业务发展的时间来区分

    1. 业务发展早期

    建议使用单体架构,开发方便,速度快,迭代更新及时。

    优点如下:
    部署简单: 由于是完整的结构体,可以直接部署在一个服务器上即可。
    技术单一: 项目不需要复杂的技术栈,往往一套熟悉的技术栈就可以完成开发。
    用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。

    2. 什么时间微服务化

    需要看业务发展速度,性能是否达到瓶颈。
    所以选择架构时,建议先单体后微服务,不要上来就搞微服务架构。

     

    二、微服务架构设计思想

    分而治之
    单一职责
    关注分离

    三、SAAS多租户

    1. 多租户SaaS架构

    小A、小B、小C大学毕业后,一起同租了一套三室两厅的房子。三个人都拥有自己独立的房间,且每个房间都有配有一把钥匙,保证三个人独立的空间私密性。如果其他人要进入别人的房间,就需要拥有配套房间的钥匙进行开锁。而客厅、餐厅、厨房等属于公共区域,三人共同享有这些资源。

    这里小A、小B、小C就属于应用SaaS多租户解决方案的企业实体。应用运行在同一个或同一组服务商(即三个人同租一套房子,厨房、餐厅、客厅是多租户环境下的系统和应用程序、组件),每个数据库都存储来自多个独立租户的数据(即房子拥有三间不同的房间),然后通过使用保护数据隐私的机制来逻辑隔离不通租户之间的数据(即每个房间都有配套的钥匙来保证安全隔离)。因此多租户架构也被称为单实例架构(Single Instance)。

    在多租户环境中,由于应用都运行在相同的服务器上,所有的数据都保存在同一个多租户隔离的数据库中,因此多租户模式通常会比较节省硬件资源。但是由于多租户SaaS架构需要具备相同的硬件、网络和操作系统配置能力,所以很难实现根据单一用户的需求去做功能上的定制化,也很难根据某个用户的请求进行常规的系统升级、重启之类的操作。

    2. 单租户SaaS架构

    如果多租户是多个人租一套房子,每个人拥有一个房间,那么单租户就是一个人租一套房子,无须与其他人共享客厅、餐厅、厨房等资源。单租户SaaS架构中,每个客户都会有独立的软件和硬件环境支撑系统运行,每个数据库仅存储来自一个租户的数据,因此单租户模式通常也被称为多实例架构(Multiple Instance)。

    单租户模式下,不同客户之间的应用软件和数据一般通过硬件来进行隔离,因此单租户模式被广泛应用在客户需要支持定制化的应用场景。每个租户可以购买特定的软件实例,通过定制化满足他们的特定需求。除了云服务提供商提供的基础功能,用户也拥有很多的可配置能力:比如,用户可以调整不同的配置需求,向内部数据库或者外部合作伙伴的数据库添加不同的模块。

    四、账户接口功能示例

    下面是账户接口功能示例:

    五、dubbo, spring cloud, k8s该选谁

    如果公司已经开始在构建微服务的路上了,那么如何选型就很关键了。
    微服务的共同关注点

    六、横向对比

     

     

    七、优劣对比


    八、技术中台

    1. 阿里巴巴中台体系

     

    传统企业平台都是烟囱式的系统架构,企业内部为了迎合业务发展不停的打造各种系统,导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力,财力还有时间。但打通烟囱式系统间交互的集成和协作成本高昂,各大企业不得不借助ESB产品,构建企业服务总线,打通各系统间的交互问题。

    但这种借助ESB“中心化”的服务架构缺点也有不少,“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点,而这个中心点的能力是很难进行扩展的,导致这中心会成为一个瓶颈。

    2015年阿里巴巴集团启动了中台战略,目标是要构建符合互联网大数据时代的,具有创新性、灵活性的“大中台、小前台”的机制,即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场,而中台将集合整个集团的运营数据能力,产品技术能力,对各前台业务形成强有力的支撑。整体内容如下:

    阿里的“大中台、小前台”架构

    起初,阿里只有一个淘宝事业部,后来成立了天猫事业部,此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系,两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因,阿里集团又成立了共享业务事业部,其成员主要来自之前的淘宝技术团队,同时将两套电商业务做了梳理和沉淀,将两个平台中公共的、通用的业务功能沉淀到共享事业部,避免重复建设和维护。后来上线的聚划算、1688、菜鸟物流等业务,均是基于这个“大中台,小前台”思路建设的。如下图所示:

    “大中台、小前台”架构主要集中在业务共享服务层,业务共享服务团队,有独立的团队来做,也更利于业务的沉淀,降低研发成本,提高研发效率。打破了产品壁垒,之前是系统之间要数据,现在是都去找共享服务中心要数据,共享服务中心提供统一的,标准的数据。减少了系统间交互、团队间协作的成本。站在巨人的肩膀上。新产品研发不用考虑之前已有的东西,可以快速孵化新的产品,试错成本低,产品敢于创新,敢于拥抱变化,原来追竞争对手都很困难,现在相当于竞争对手的产品经理不停的给我们提供新点子。可持续发展,技术和业务能力能够沉淀积累。

    “大中台、小前台”与微服务的关系

    微服务体现去中心化、天然分布式,与阿里的中台战略思想类似,是战略的具体实现方式的一种。现有架构师可以学习这种模式来解决企业本身的应用高并发、高可用、运维等难题,也是现有互联网经典架构,毕竟是经过阿里实践过的,除了BAT,Uber、网易、美团、京东等互联网公司都在很早前就实现了平台微服务化。

    2. ebay中台体系

     
  • 相关阅读:
    二分+RMQ/双端队列/尺取法 HDOJ 5289 Assignment
    思维题 HDOJ 5288 OO’s Sequence
    树形DP Codeforces Round #135 (Div. 2) D. Choosing Capital for Treeland
    最大流增广路(KM算法) HDOJ 1853 Cyclic Tour
    最大流增广路(KM算法) HDOJ 1533 Going Home
    最大流增广路(KM算法) HDOJ 2255 奔小康赚大钱
    Complete the Word CodeForces
    Gadgets for dollars and pounds CodeForces
    Vasya and Basketball CodeForces
    Carries SCU
  • 原文地址:https://www.cnblogs.com/skyme/p/13681189.html
Copyright © 2011-2022 走看看