完整代码地址在microfrontend-learning 1. 创建项目主应用是使用vue开发，两个子应用分别是vue、react， 创建命令如下：# 创建主应用
vue create app-main
# 创建一个app-vue的子应用
vue create app-vue
# 创建一个app-react的子应用
npm install -g create-react-a
1.应用背景传统的登录系统中，每个站点都实现了自己的专用登录模块。各站点的登录状态相互不认可，各站点需要逐一手工登录。这样的系统，我们又称之为多点登陆系统。应用起来相对繁琐（每次访问资源服务都需要重新登陆认证和授权）。与此同时，系统代码的重复也比较高。由此单点登陆系统诞生。单点登陆系统单点登录，英文是 Single Sign On（缩写为 SSO）。即多个站点共用一台认证授权服务器，用户在其中任何
本文你将学到什么？本文是《手把手项目实战系列》的第二篇文章。上一篇《手把手0基础教你搭建一套可自动化构建的微服务框架(SpringBoot+Dubbo+Docker+Jenkins)》受到巨大好评，在这里也深表感谢。应大家要求继续完成后续章节的撰写。上一篇的实战过程介绍的“高喜商城”项目其实是一个真实项目，它是一个标准的在线商城（为了避嫌，“高喜商城”是我随意起的一个假名字），这个项目的很多技术具
随着架构的演进,从大杂烩到现在的微服务,架构发生了变化,那自然很多的东西也要随之改变,今天我们来说一说这个单点登录又是什么东西. 首先在分布式的结构下,一个项目被拆分成不同的微服务,每个微服务之间做着自己分内的事.然而有些需求却需要贯彻这整个项目,比如说登录,用户在一处登录后,访问项目中的每个微服务所管理的部分都应该实现已登录功能,在传统的单一服务器登录中,我们可以实现用session存值,
微服务框架微服务框架要如何进行拆分微服务框架的拆分思路其实跟数据库的分表分库的思路其实是一样的，我们刚开始后台的时候，通常都只有一个表一个库，但是当我们的服务被越来越多的人使用的时候，就会发现一个数据库超过了一个限度（通常我们把这个限度定在500万行或者是1TB的数据量），这时候我们就要分表分库了，而微服务框架拆分的思路也是这样子，垂直方向拆分，水平方向拆分。业务功能单位的垂直拆分 
纯属杂谈笔记，没有啥实质内容。。传统互联网应用的架构演变简单来说，从 单体应用 -> 集群负载均衡 -> 动静分离、cdn分发 -> 数据库读写分离 -> NoSql 缓存 -> 分库分表 -> SOA -> 微服务具体可以看看这篇文章什么是微服务将一个大型应用，拆分为多个独立的小服务，相互间通过rpc接口进行调用其他服务，最终完成整个大型功能的一种架构思
前言之前总在聊微服务， 微服务本身也是分布式系统，其实微服务的核心思想是分而治之，把一个复杂的单体系统，按照业务的交付，分成不同的自服务，以降低资深复杂度，同时可以提升系统的扩展性。今天想聊一下分库分表，因为对于快速增长的业务来说，这个是无法回避的一环。之前我在做商城相关的SAAS系统，商品池是一个存储瓶颈，商品池数量会基于租户增长和运营变得指数级增长，短短几个月就能涨到几千万的数据，而运营半年后
之前在学习微软的示例eShopOnContainers时发现它使用的是单体代码仓库库，之后又发现大家在进行微服务项目开发时也都在使用单体代码仓库。问题来了，为啥要微服务项目都要使用单体仓库（所有微服务都在一个代码仓库）呢？1微服务应用的代码仓库组织我们都知道，微服务应用相对于单体应用来说，最大的好处就是可以独立开发、测试、部署和扩展。单体应用一般会采用单体代码仓库，但是微服务应用的代码仓库应该如何
一、分库分表理论篇什么是分库分表？垂直分库 把数据库按照业务分库垂直分表 将表按照列进行拆解水平分表为什么要搞分库分表？数据库中的表太多----分库----微服务（应用和数据库都是单独的，比如说用户模块， 用户相关的表在单独的数据库上）分业务库是为了减少数据库的访问压力，根据业务模块进行分库（一般为了体现分库 的好处，都是单独讲一个库进行部署到Linux）记住：不要使用docker技术来部署数据库
学习思路业务初期单库优缺点什么时候开始选择分库分表，具体实现方案sharding-jdbc原理讲解sharding-jdbc实现方案一、业务初期单库优缺点业界传烂的一句话：能不分库分表就不分库分表；带着句话我们来分析一下单库优点：实现简单，只需要简单配置数据源事物控制简单，可以保证强一致性数据查询简单，不需要依赖第三方聚合工具缺点：初期无缺点如果达到一定数据量，单库可能存在瓶颈回到第一句话，业务初
1、服务拆分原则不同微服务，不要重复开发相同业务微服务数据独立，不要访问其它微服务的数据库微服务可以将自己的业务暴露为接口，供其它微服务调用2、服务拆分示例 cloud-demo：父工程，管理依赖order-service：订单微服务，负责订单相关业务user-service：用户微服务，负责用户相关业务要求：订单微服务和用户微服务都必须有各自的数据库，相互独立订单服务和用户服务都对外暴露Rest
前言从本文开始，我们进入了《从分层架构到微服务架构》系列中分布式架构的介绍，本文要介绍的是服务化架构（Service-Based Architecture，SBA）。SBA 可以看成是单体架构和微服务架构之间的一个折中方案，它也是按照业务领域进行服务划分，但服务划分的粒度相比微服务要更粗。SBA 与微服务架构一大不同是，它允许各个服务间共享同一个数据库实例，这也使得 SBA 在架构上既有单体架构的
一、系统架构演变最开始接触Java语言的时候，我写的第一个项目是图书管理系统，当时是用JSP+servlet写的，感觉很吊的样子，全班领先水平。慢慢的变成了JSP+SSM架构。到现在单体架构最流行的SpringBoot+Vue。但是，随着业务量的不断增大，你会发现，这些单体架构，已经无法满足数据日益膨胀的今天，动不动就几万、几十万的QPS，我记得当初200QPS，我就觉得挺吓人了。为了解决性能问题
前言一般来说，影响数据库最大的性能问题有两个，一个是对数据库的操作，一个是数据库中的数据太大，对于前者我们可以借助缓存来减少一部分读操作，针对一些复杂的报表分析和搜索可以交给hadoop和elasticsearch,对于后者，我们就只能分库分表，读写分离。互联网行业随着业务的复杂化，大多数应用都会经历数据的垂直分区，一个复杂的流程会按照领域拆分成不同的服务，每个服务中心都拥有自己独立的数据库，拆分
场景中国现在有9亿网民，我们随便一个人做点什么都会产生大量数据，比如看一下视频发表一下感想。 点赞57万，投币45万，评论1W+，再比如前段时间的618购物节，无数网民疯狂购物产生无数的消费数据，这么庞大的数据量该如何存储？前言我们都知道mysql有性能瓶颈，当数据量到达2100w左右的时候，效率就会大幅下降。mysql> show global variables like '%page%
好多年没发博，最近有时间整理些东西，分享给大家。所有内容都在github项目liuzhibin-cn/my-demo中，基于SpringBoot，演示Dubbo微服务 + Mycat, Sharding-Proxy分库分表 + Seata分布式事务管理 + ZipKin, SkyWalking, PinPoint性能分析链路跟踪APM工具，有详细文档，可以快速运行演示项目架构运行演示项目packa
1.根据视频划出重点摘要除了飞哥的视频，再去找一套视频，进行补充，会有非常好的认识。不要单一依靠某人，而是多去听不同的教程资料，选出更加符合自己需要的那一套是非常重要的。 数据量大，并发量大，肯定想着分，把服务分出去，建立集群，搭建微服务。 肯定和团队沟通，如何去实施这些方案。为什么不用nginx进行负载均衡，而是使用Ribbon 1.nginx不是springcloud的技术栈 2.nginx配
分布式事务CAP定理CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效) 可用性(Availability) ： 每个操作都必须以可预期的响应结束 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成 具体地讲在分
一.微服务概念 X轴：运行多个负载均衡器之后的运行实例，是水平复制。比如讲单体系统多运行几个实例，做个集群加负载均衡的模式。Y轴：将应用进一步分解为微服务（分库），是微服务的拆分模式，就是基于不同的业务进行拆分。Z轴：大数据量时，将服务分区（分表），是数据分区，比如按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。举例：比如打车APP，一个集群撑不住时，分了多个集群，后来用
微服务概念微服务是将单一服务按照业务独立分开，共同组成稳定的应用系统。每个服务可单独部署、弹性拆分、相互通信。服务的拆分符合低耦合，高内聚的特性。从而降低每个服务间的代码复杂度，提高整个系统稳定性。所有服务遵循统一的分布式管理，统一的通信机制。每个微服务可以使用不同的代码开发。微服务架构可以看做是面向服务架构和分布式架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。微服务
