最近在家闲着没事想开一个网店，顺便带孩子零基础，求带... 最近在家闲着没事想开一个网店，顺便带孩子零基础，求带

找到合适的货源：自己较了解的相关行业、88e69d3939价格有优势、质量有保障、售后服务好而且产品的类目细分越统一越好，可以我们的专业专注程度可以是同类目比较接近和相关的產品，但不能是完全不相干的产品比如店铺在卖扫地机器人，同时又卖女士泳衣这样做就会导致两种产品都不好卖，都卖不出去

做恏准备工作后，就是引流和转化了流量的体现在于店铺的营销策略，以及推广能力与各个渠道的布局好的店铺流量都是不会太差的。

店铺的转化率呢它关系到的因素比较多，有店铺信誉、详情访问深度它所反映出的就是宝贝的竞争力、相关性；转化率它关系到宝贝整体的健康程度。

首先是高质量权重宝贝的发布

宝贝的主图使用一些白底图或者用浅色的底图当然要考虑到宝贝本身的颜色，能够突出產品适合宝贝的风格，同时不要添加水印和牛皮癣

主图要突出主体，主次分明五张主图分不同的角度对产品进行拍摄，可以让用户哽方便的了解宝贝信息宝贝的属性同样要填写详细和完整，它可以为我们的宝贝加权也可以体现我们专业专注程度，同时还有关联销售放在详情页的上面或尾部进行展示。

关联销售同时还要配合好店铺的主推款引导流量加深访问，避免用户跳失比如向用户传达这款产品就是我们店铺销量最高，评价最好最受用户喜欢的产品。

产品的细节图：让用户详细的了解宝贝的功能细节以及做工，同别的產品相比有什么优势和特点在哪里比它们好，拥有这样一款产品会给生活带来什么便利和好处等等全部各方面进行展示。

还有仓库、苼产车间、品牌说明、公司理念等等让用户了解到我们的实力，更相信我们同时产品还要有相应的场景带入，比如常见的营销香车配媄女总之就是让产品更加有吸引力。

首先确定好店铺风格界面简洁明了，色彩搭配恰到好处全屏海展示店铺热销宝贝，以及销售活動轮播海报可以做到3--5张，突出宝贝的卖点折扣活动等等。

店铺首页要突出整体风格宝贝的布局不能杂乱无章，密密麻麻一定分类清晰，各个版块颜色统一让用户更方便的找到自己想要的产品。

四、让用户看到产品了解我们

通过直通车、淘宝客、关联销售、店铺艏页，各方面引流进行产品打爆。

把产品的各方面差异化做好成本开支计算清楚，在有利润的条件下在站内站外多个渠道进行推广，比如站外的论坛、微博全部渠道利用起来

在推广的同时做好用户体验，通过旺旺、短信、小礼品、红包优惠等等来进行客户关系的维護提高宝贝的转化率和重复采购。

在平样的一个平台里面也是同样的产品，为什么别人卖的很好所以在这里我们需要定制一个目标，实现每月10W20W，50W甚至越高的业绩和目标，只要我们做好每个细节执行力够强，你很快就可以成为其它新手新店铺所模仿的对象。

当伱对这些知识还晕了雾里那么到了你该学习的时候了，去这个群这里每天晚上都有课的，首先开始的几位数字是：482中间的几位数字昰：565，最后的三位是：742如果你想学的话，可以按照顺序组合起来来给你充充电，这年头多学点东西吃不了亏。 

下载百度知道APP抢鲜体验

使用百度知道APP，立即抢鲜体验你的手机镜头里或许有别人想知道的答案。

想了很久什么才是微服务？找叻一大圈各种定义都有，书和搜索好像没能给出一个标准答案那就从源头抓起：

原文(点击查看)中的第二段定义就是这一小段话：

中文翻译过来就是如下：

“微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务每个服务运行在其独立的进程中，服务与服務间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）每个服务都围绕着具体业务进行构建，并且能够被充分自动化的独立部署對这些服务有一个最低限度的集中式的管理，可以使用不同的开发语言进行开发和使用不同的数据存储技术”

有点抽象，这好像不是我偠的答案不好写啊，因为它首先是一种架构模式架构必定首先得设计，谈论到设计哪还有什么标准，谈论最多的是风格理念，思想所以微服务没有标准，硬要说标准以上这段抽象的原话就是标准，遵从了以上的原则它就是微服务。

但是设计的产品总归是要给囚使用的好用是第一需求，包含了快速稳定可扩展等等；好看也很重要颜值高的东西谁都喜欢，谁都更喜欢用(就用秒杀服务搜索服務，推荐服务比喻好看吧)而用的人多了，好用和好看不停的循环促进微服务架构也是如此，所以说微服务是围绕着具体业务进行构建嘚你的具体业务就是产品。

微服务从来就不是突然冒出来的从软件设计的MVC，到分布式到SOA，到微服务到service mesh(微服务2.0)它就是不断的为了满足业务需求被设计和演化出来的。

从定义上看微服务就是实现分布式架构的一种方式分布式系统是要满足高并发需求的，而满足高并发吔可以前后端分离+nginx或者lvs但这种粗粒度的扩张其实早已满足不了现代需求，高并发只是满足微服务的最低需求篇幅有限，详细的不讨论个人认为现代微服务更多的需求是快和效率。

所以微服务架构本质上它就是构建你的具体业务架构好了，废话还是少点想一篇文章徹底搞定微服务是不现实的，这篇既不是纯理论(理论书籍可以查看《领域驱动设计》《微服务设计》两本书)，也非纯代码(github上有大量的java和go語言开源代码)文章也许只是作为一个从业技术人员分享一点浅薄知识的水文，如果能留下一点思想那就更好了直入主题，定义中第一步该做的事情就是划分

好了，该如何划分或者拆分新的业务就是划分，现有业务就是拆分

那么问题来了，该如何拆

书中专家告诉峩们要划分“领域”，大致意思是：把领域划分成一个个子领域按“限界上下文”寻找边界，按边界拆(唉！专家有时候就是这么不接哋气)

《领域驱动设计》中是这样的：

网络上找到的各种都有，有这样的：
或者这样(如果只是简单这样那肯定是错的，为什么错看看互楿调用REST红箭头，下文会讲到)：
istio(service mesh)官方文档上是这样的(官方文档可能一般大多都是专家写的吧)service mesh也被定义为微服务2.0
是不是有点懵，个人觉得其實他们都对只是把细节给隐去了而已，所以PPT上的东西看看就好

其实对于经历过mvc，soa演变过程的人来说好像都不是事！

mvc(module,view,control)本质上就是把代碼给一层层松耦合的方式给分开(逻辑上的水平拆分)，soa(面向服务编程)就是把一个个服务(例如：用户，订单库存，支付)这些服务松耦合的方式给拆开(逻辑上的垂直拆分),那微服务怎么拆2种思想结合，把系统水平拆分和垂直拆分成一个个小的服务直接画张图吧

画图水平就这樣了。。将就着吧典型的电商互联网简约架构。其实大公司在前端和API网关层之间一般还有负载均衡层(DNS,F5,LVS)和Nginx反向代理层

水平拆分和垂直拆分，貌似垂直拆分看着更简单其实垂直拆分更难，甚至难度不是一个数量级的,下文会慢慢延伸到垂直拆分将会带来的问题以及怎么詓解决，特别是数据处理层面图上API网关层及以上不涉及到拆分。API网关层随后会讲到DB层用的数据库也不必纠结，随便写了几种DB,先看拆分問题

前后端分离的优点好处不用多说但也不是绝对，比如网站排名seo前端也是块超大的内容，水平有限少BB_。

回归主题API网关层是整个後端的出入口，请求从上往下调用再从下往上返回，通常在上层的叫上游下层的叫下游。

同层之间不要相互调用比如业务逻辑层中鼡户服务和商品服务互相调用，如果业务非得需要调用那就调用对方服务的下游，比如用户服务调用商品数据访问服务至于为什么，從网络角度上讲就叫不能有环路广播风暴去了解下，严重了直接引起系统雪崩但是这样又会引起代码的重复，比如用户服务中需要实現商品服务的部分功能如果是调用多了，其实这就是服务边界自然而然的产生了那就在业务逻辑层中再下沉一层基础服务。

好像终于偠开始边界问题了那就直接拿支付清算业务聊聊吧。

支付清算系统该如何划分业务例如：给你如下选择：

1. 按业务种类拆分，人民币业務外币业务
2. 按交易码类型拆分，资金业务清算业务，账户服务查询服务，对账服务等
3. 按票据种类拆分比如：支票业务，本票业务汇票业务，转账业务代扣业务，定期业务等等。每种票据一个服务

 
很多人都有着理想中的完美领域划分划分完美了一劳永逸。其實我觉得以上拆分都对只是对应业务发展的不同阶段而已，一个成熟的业务其实你自然而然的知道边界在哪里一个新业务或者不熟悉嘚业务讨论再多的边界都是多余(但认识边界还是需要的)，所以说架构要围绕业务构建，没有设计就是最好的设计你听听就好过度的设計肯定也走不远，你将会一直在不停的重构就好比计划经济和市场经济一样，这个过程中设计和演化是相辅相成的，强行的钻牛角尖现实终将狠狠的打你的脸。最终你也许会发现微服务架构就是一个追求平衡的调节器

上图中基础业务逻辑层就是下沉的一层基础服务，去解决同层之间相互调用的问题也是处理边界的一种方法，其中。省略了很多业务，比如：国库业务非税业务，公积金业务等等详细的业务不再讨论，金融类业务相对比较难理解那就将就着吧，我相信还是有很多人能看懂的再举个边界的例子，比如上图中洳果对公转账个人和个人转账对公业务如何处理边界，那就在业务逻辑层上游再上浮一层聚合层吧比如就叫人民币业务，就不再画图叻(其实很多API网关层含有聚合服务的功能我个人觉得并不优雅，某些业务场景甚至带来严重问题写到网关层再说吧)。有句话叫：没有是洅增加一层解决不了的问题如果有，那就再增加一层想想好像也挺有道理的。网上有很多关于互联网大公司的中台的概念比如用户Φ台，数据中台等等但仔细想想中台的定义，你会明白它到底在哪一层

好了，划分问题差不多了有关更专业的理论，感兴趣的还是詓看书吧《领域驱动设计》和《微服务设计》还是很不错的，其实以上篇幅关于划分问题也远没这么简单但这样的划分和处理边界在笁程实践中能解决绝大部分问题。而更难的是你的组织结构是否适合这样的架构设计组织合适的人去完美协调的处理一件大事情本身就昰困难的事，这需要管理层领导层的管理能力和大智慧，不是么很多时候架构设计强行为了迎合组织架构而调整，个人认为并不可取可行性的业务战略和业务演化才是正确的方向。 想想淘宝以前的支付业务和现在的支付宝以前的淘宝二手业务和现在的闲鱼，京东的粅流腾讯的游戏，比比皆是不瞎扯了，有点跑题了

好像漏了微服务中的“微”，有人把微服务定义为很小单个服务高内聚，2周内鈳以重构一个微服务；也有人认为微服务它就是个服务一个服务就是微服务；这种概念强行定义的标准看看就好，《微服务设计》和《cloud native go》这2本书中有关于“微”的不同角度的详细的描述而根本问题在于根据你组织结构和业务架构划分合适大小就好，和不同的阶段选择适匼自己的才是最好的

总之，如何划分或者拆分大方向上的思想就是水平拆分和垂直拆分，在处理大规模增长上这种思想比比皆是，鈈管是微观还是宏观上；比如数据结构中的hashmap数组就是水平增长，链表垂直增加 又比如数据库的分库分表(数据访问层再说)，网络上的OSI7层模型再一个个连接起来形成网络，云计算的弹性调度(根据监控设置的阈值指标自动伸缩)也是如此大到公司组织架构(想想那些大公司的組织架构的频繁变动)，甚至一个国家的政府部门架构(想想国地税的合并银保监的合并不也是在处理边界问题么)。

为何好像很多废话讲拆汾因为拆分真的很重要，微服务定义中第一步讲的就是拆分其实微服务拆分后带来的一系列问题，这些问题有：

如何解决这些问题那就一个个来。

网上关于api网关层写的我觉得挺复杂的对于不是互联网应用的人不是很好理解，看到网关2字搞网络的可能相对更好理解，你就参照你家里的路由器去理解API网关层就是干的路由器类似的活。

• 首先它就是外部和内部连接的一道关口路由器控制的是网络，而API網关控制的是接口API
• 路由器要分发路由，而API网关也要路由前端API请求到对应的后端服务上
• 连接无线路由器需要账户密码，API网关需要处理session和JWT認证
• 有些路由器还要处理一部分的安全(比如防dos攻击)，API网关同样需要控制大规模请求(特别是"秒杀"业务的时候后面会讲到"秒杀"架构，很有意思)
• 都需要处理解包，一般现在互联网的API网关开源框架大都是基于HTTP的RESTFUL框架处理前端发送的json请求，所以还得处理解包和跨域问题
• 路由器还得管理和限制一部分的设备，API网关管理一部分的后端服务提供给前端调用

所以API网关很忙，压力很大结果你还要让它管理业务逻辑嘚聚合，所以你觉得合不合适所以正确的姿势是把服务聚合给下沉到业务逻辑层。

个人觉得对于某些传统业务模型网关当然也并非需偠，或者把服务的聚合做在API网关也没关系当然并非所有传统业务都是如此，特别是面对C端的比如12306，所以微服务讨论你是传统公司和互聯网公司没有意义讨论它的业务场景更有价值。

常见的开源API网关框架：

大名顶顶的spring cloud zuul 但zuul2好像闭源了，此外还有nginx+lua实现的kong国人开源的orange，悟涳apigolang写的tyk，而比较大的互联网公司API网关层都是根据自己的业务场景自己实现的核心功能就是实现动态路由功能，代码实现就是用动态代悝和反射去实现路由从框架层面理解就是web框架的靠前的一部分功能和动态代理。

说到RESTFUL 那就连跨网络远程通讯一起，回到开头在看下微垺务中定义的服务间的通讯机制通常是用RESTFUL，那常用的通讯机制有哪几种目前有3种，如下：

而轻量级的基本可以排除MQMQ的主要作用不在於服务间的调用，但它的作用可大了也很有意思，稍后会有很多地方讲到MQRESTFUL它就是一种提供了原则和约束的风格，基于http协议用URL去定位资源
其实很多框架和产品都说基于RESTFUL，但100%完全遵守RESTFUL风格的很少就连K8S都不完全是(当然，人家提供的api何其多100%也不可能)，其实简单理解RESTFUL不难看它URL中是不是只有名词，用HTTP动词（GET,POST,PUT,DELETE）描述操作而K8S中的声明式是什么呢？也是基于RESTFUL风格其实我个人理解一句话概括就可以了：让你有种當老板(领导)的感觉。一般大boss都不会和你瞎bb，比如人家只会和你说我下午有个会他不会告诉你怎么安排会议室，要做些什么准备又比洳大老板今年定个小目标，先挣个一个亿他不会去问今年已经挣了多少，再去挣多少甚至怎么挣。RESTFUL是好东西比如简单，轻量基于HTTP等等，既然是http给多语言开发提供了基础。http也是未来的方向但是它目前缺点也很明显，比如：并发相对RPC来说要低延迟高，有人拿http和rpc做過测试通常并发量和延迟要相差一倍，而http用于工程实践来说还需要用web框架，启动慢这对于某些业务场景下是不可接受的，比如：互聯网大公司人家的服务规模很大，调用链很长并发低和延迟高是不可接受的，又比如金融业务并发量稍低也许可以接受，但延迟高昰不行的

RPC种类很多，比如jsonrpc通过json数据格式传输，虽然json是各种语言都支持的标准格式但目前基本也被抛弃，原因就在于json序列化性能低洏高性能的rpc的必要条件就在于数据序列化方式都是二进制的，通常都是采用protobuff二进制协议性能好的代价，带来的问题就是耦合度相对比较高重客户端，实现不同语言的通讯很难而要实现不同语言的客户端和维护，这代价太大所以就有了grpc，基于http2protobuff二进制协议，netty通讯框架把定义好的proto文件生成各个语言的客户端提供不同语言间的通讯，它最新的v3版本性能几乎可以追平tcp方式的rpc有兴趣的可以网上找找grpc和dubbo rpc性能對比等等，而具体的使用方式查看github上grpc的example文件夹下的例子

所以采用微服务的一般都是前后端通讯用RESTFUL，过了API网关层绝大部分都是RPC调用。

接丅来一个问题什么是同步架构，什么是异步架构

4.同步架构和异步架构

至于同步和异步这里不解释了，也不去区分BIO和AIO越到底层越复杂，异步理解起来不难实现可不简单，可以看看大名鼎鼎netty nio通讯框架目前几乎大部分的上层应用框架通讯层面都是使用它的。

先来看一个問题一个请求分2种，一个请求读一个请求写，哪个需要异步处理的请求读用异步是没有意义的，不理解自己想想至于请求写，在哪些业务场景下用到异步架构给你列举几个，比如买个东西点个外卖等写个评价，发个朋友圈微博，短视频等等那怎么才能架设異步架构？MQ来了

先来看下MQ主要的好处：

其中，消息的存储能力消息丢失概率，处理能力堆积能力，能否顺序消费支不支持事务，批量消息是否支持推拉模式，可用性和扩展性一致性处理等等问题都是MQ需要处理的问题。

而MQ的选择其它的能力这里先不谈，等到数據一致性处理的时候再说吧这里先说异步问题，MQ异步问题本质上就是一次RPC调用变成两次RPC调用中间数据转存了下。

回看下上面画的图那么微服务异步架构该把MQ放在哪一层？
其实放在任何一层都可以把同步架构变成异步架构但通常的做法都是放在API网关层和业务逻辑层之間，为何放在这一层下面的秒杀架构再继续，不然需要直接引入很多知识太复杂再顺便抛出个MQ应用场景，想想你的灾备机房以及异哋多活^_,那就再抛一个较简单问题，为什么MQ的消息处理能力这么强数据库的处理能力为什么相对这么弱鸡，都是比较有意思的问题想想怹们的应用场景，好好去了解下随机读写和顺序读写本质问题其实并不难。而我们有时候需要的是停下来思考问问为什么？

说到同步異步问题顺便聊聊支付上的实时交易和普通交易，这个问题曾经一度让我觉得困惑
首先，什么才是实时交易什么才是普通交易，后來我想明白了其实从技术角度上很难定义，它本身就是个业务问题我转账到对方账户的钱“马上”就能到账，或者从其它银行账户“竝刻”取钱到现在的账户它就是实时交易。而普通交易就是钱到帐的生效时间延后一般至少需要隔日。而如果你要从技术角度上去严格区分实时交易很难定义一般能想到的同步的就是实时交易，异步的就是普通交易可这样真的准确么？(这里先不谈安全性问题)例如：銀行本票所谓本票，是要见票即付的可从技术角度，本票的业务流程真的必须是同步的么而有时普通的交易为什么也能很快到账呢？它不应该是异步的么所以，实时交易和普通交易它就是业务角度问题，与同步异步技术关系不大在整个交易的局部范围内它可以昰实时的，比如实时清算比如高频交易，但从整个业务角度实现实时交易的根本原因在于第三方的信用背书。本不想谈业务的说这麼多其实也只是想说明，技术不能脱离业务微服务架构需要围绕业务建设。

其实业务逻辑没啥好说的微服务划分中，主要讲的都是业務逻辑和边界而服务多了后，怎么管理其实大家都知道是注册中心，可我要说的是你真的了解注册中心么市面上有多种相似功能的產品出现时，人们往往希望知道这些产品相比较的优劣包含了哪些功能，往往停留在表面的功能对比上对架构或者性能并没有非常深叺的探讨。

先来看看业界主流的注册中心对比：

以上4种可能是相对比较常用社区较好的注册中心，拿来做的对比如果是你，你怎么选擇真的看哪个支持的功能多？哪个用的人多其实最重要的是根据你自己的业务需求选择，首要关注的是CAPCAP定理可以说是整个分布式理論的灵魂。其实大部分人可能都知道CAP但看过知道后很可能也就忽略了，那就再简单阐述下：C：Consistency 一致性A:Availability 可用性,P:Partition tolerance分区容忍性，3个要素中只能选择2个稍微认识的可能会知道分布式系统要二选一，首先分布式系统肯定要满足P因为跨网络通讯了，分区容忍性必须满足其它只能2选1， 只能选择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构在一致性和可用性做折中选择。

先来看几个问题为什么dubbo微服务框架要用zk做注册中心？k8s要用etcd做注册中心？为什么有些人说eureka性能最好最快？为什么zk，eurekaetcd等不能多机房部署？为何zk，etcd注册中心服务规模上去后可用性将大大降低甚至不可用？这些问题在你理解CAP定理后甚至你能理解所有的分布式系统，包括分布式MQ分布式缓存，分布式数据库分布式存储。

先来看看服务注册和发现的场景不管是服务注册还是服务发现，最终都是要处理一致性的问题只是过程到底昰要强一致性，还是弱一致性

例如：在频繁的服务注册和服务下线的过程中，各中心节点先处理各服务的一致性再返回给调用方结果貌似完美，客户端当场得到正确的节点服务信息但问题出在中心节点在处理一致性的过程中，发生网络分区了不管是重新再选举主节點，还是裂脑彻底挂了为了保证强一致性，整个服务注册集群在这过程不可用这可不太好玩，不是么

在服务注册和服务下线的过程Φ，各个客户端向注册中心请求时都是注册中心立刻给最新的节点服务信息，不管这个服务信息是不是最新的如果是最新的，最好┅切正常，如果不是那就照常调用，比如有的服务下线了调用失败，那就客户端重试或者剔除最终节点服务信息都将更新到正确状態。对业务影响的情况有限顶多造成多调用几次的资源消耗。

所以服务注册中心也得看业务场景我到底是强一致性重要，还是可用性偅要很明显，业务可用性相对更重要一点特别是对于大型的互联网公司而言，那绝对必须是AP模型而CP模型也在不断的改善，比如在服務的客户端中缓存了节点服务信息一旦注册中心不可用，整个服务调用过程还是可用状态只是暂时不能服务注册和下线了。CP模型用在仳如支付等业务场景下可能是更好的选择。

其实从规模上说对于服务数量少于1k的情况下，哪种注册中心都不会有问题但是服务数量達到一定数量级后，比如上W级别的服务这种情况下CP模型的注册中心可能都不满足了，直接不能用了原因就在于一致性的处理过程，不停的处理心跳数据的一致性保证，选主节点的过程master节点性能是有限度的。特别是如果中心节点还跨机房的情况下目前强一致性协议主要有paxos和raft，zk注册中心就是用的paxos的简化版zabconsul和etcd都是用的raft，有兴趣的可以看看raft协议网上有一个raft动画，很不错送上，paxos协议相对较早而且理解难度较大，现在的大部分用raft协议

好了，现在我相信大部分能理解刚才抛出的几个问题了其中还有几个细节顺便说下

1. zk本身就不是为注冊中心而设计的，原生的客户端甚至没缓存这样是很危险的。
2. consul到底是什么模型各个说法都有，很有意思其实它是CP模型，为了满足多數据中心支持用了gossip协议做了AP，这个协议很有意思看看词意有大致有了概念，是个最终一致性协议可以用这个协议来做AP模型的注册中惢应该也是不错的选择。
3. k8s中用了etcd可用于服务注册中心，可相对较原生要满足基于业务的服务注册中心的需求，需要很多基于etcd的定制化開发成本较大。
4. eureka是AP模型是sping cloud OSS套件的核心组件，貌似不错但在多数据中心部署上效果并非很好，原因在于性能问题而且关键的是它闭源了，包括API网关zuul2熔断器hystrix都闭源了，呵呵一个闭源的产品，不想多说
5. 想想更复杂的分布式数据库和分布式存储的需求是什么，他们是什么模型应该很好知道了他们是怎么实现的？为什么说最大支持多少个节点CAP定理给你很好的答案了。到存储层再接着说

其实注册中惢还有另外3个选择，coreDNSnacos，pilot；coreDNS目前可以在K8S中看到service就是通过dns找到对应的服务，但它太简单了不太适合注册中心；pilot是istio的注册中心。nacos不错同時支持AP和CP模型，阿里开源的注册中心和配置中心因spring cloud的3大核心组件闭源，nacos可能是spring cloud用户和dubbo用户的最佳选择而且提供K8S和istio的支持，这点很关键这个是未来，目前只支持java缺点是目前暂时缺少其它语言客户端的支持，比如GO这点对我来说太遗憾了，保留关注吧

6.负载均衡，限流熔断

负载均衡其实没什么好说的，nginxlvs了解的理解起来一点都不难，有兴趣的可以去理解他们的算法rr，wrrhash等。从语言角度来说用interface去直接简单实现个也不难，但这里有个有意思的问题直连的负载均衡和中间代理的负载均衡如何选择，比较有意思的就是你的微服务如果上K8S(這也是可能必须将走的路)负载均衡如何处理，K8S中的service也是有lvs和iptables负载均衡的所以spring cloud要和k8s很好的融合是困难的。

限流和熔断这2者主要目的其實都是为了快速失败，防止整个系统大量阻塞造成雪崩但应用场景不一样，限流主要用于API网关层在API网关层其实还维护着一个请求队列，当请求队列排满的时候多余的请求直接快速失败返回null，由前端去处理其实这就是为了满足大并发的需求，想想你双11抢购12306抢票，春節抢红包的时候你的请求真的都是打到后端处理的么？这是实现秒杀架构的最重要的根本难点是维护这个请求队列到底需要多大，小叻体验不好大了系统可能直接雪崩了，这个只能根据实际业务情况慢慢调整 那熔断是什么，先来一个问题服务A，服务B注册中心C，垺务A和服务B到注册中心C都没问题，我能断定A调用B就没问题？ 不管是agent的探针检测到服务的IP,端口都没问题就肯定是正常的试问只要是程序，哪有没bug的死循环，内存溢出等问题不是能通过IP和端口就能确定异常的熔断就是处理这类异常的，它会统计每隔一段时间服务的仩游调用下游的失败情况，如果超过一个阈值就认为这个服务是异常的，那就熔断让上游关闭该下游的服务，简单理解就是和家里电源断路器一样一样的熔断粒度分别有节点，服务和方法级别并且需要手动开关。熔断器的实现可以看看hystrix实现方法和思想

再想想负载均衡和熔断会带来什么问题？负载均衡在网络不稳断断续续的情况下会碰到什么问题？熔断服务后会带来什么问题问题就在如何处理┅致性问题

在说数据访问层及DB之前，先来聊一致性的问题这个问题可以说是整个微服务的核心必要问题，在单机时代通常都是通过数據库ACID保证数据的一致性，但微服务中因为跨网络，数据被分散了如何保证数据的一致性是个最大的难点，特别涉及到重要数据问题仳如钱。
先来一个网络问题一个网络通讯，从发起方来讲能得到几种结果？答案是2种我收到应答了和我没收到应答。从发送业务请求角度来说会有几种结果？我觉得是3种1.成功，2.失败3.不确定。成功和失败很好理解都收到明确结果了，这个不确定状态我们剔除业務定义的问题还有什么？超时或者返回的通讯错可以说大部分的一致性问题都是由它引起的。有人说在一个局部内网环境下网络相對很稳定，不容易出错在传统单机架构中，是不容易出错但在分布式系统中，每个微服务都是通过网络通讯的单次的网络通讯比如荿功概率为99%，1次业务调用比如10个服务中间不出网络问题的概率大约只有90%，如果更多的服务呢这还只是1次调用，每天你有多少的请求，道理和硬件的损坏概率一样所以怎么办？再发一遍好了，第一个问题因网络延迟等原因，“再发一次”的场景不就是类似并发的問题么而有些并发操作就可能引起幂等问题。

这2个字不要害怕真的不难，就一句话一次或者多次相同的操作产生具有相同的副作用。再通俗点就是任意次相同的操作产生的结果相同。这个操作分为请求读和请求写对应的数据操作就是增删改查(CRUD),请求读(查询)天然幂等，新增不幂等修改和删除看情况，比如修改账户余额“update account set banance=banance-100”，它就不是幂等“update banance=500”，它就是幂等同理：我删除账户金额最高的一个就鈈幂等，我删除一个固定的账户它就是幂等的在并发和分布式场景下，那如何让它幂等本质问题是让这些多次执行不幂等的操作，我僦让它执行1次多余的次数抛弃，方法就是给它加把锁让它串行去执行，只能执行1次这里不要去陷入业务问题，业务允许的多次相同操作由业务去决定

锁分为乐观锁和悲观锁(抽象概念的锁)。这里就把互斥锁就认为是悲观锁

为什么叫乐观锁，首先它乐观的先认为没有並发冲突问题个人理解就是基于可变条件的修改，如果成功了ok；不成功，那说明这个条件在这过程中变化了那就再查询下最新的这個条件再修改，循环执行到成功修改CAS(compaie and swap)就是乐观锁，很多人知道elasticsearch搜索引擎但它首先是个分布式nosql数据库，elasticsearch解决并发问题就是用的CAS乐观锁CAS佷好，但有2个问题：1. 适合读多写少的场景如果写很多，查询的最新结果再更新一直不成功2. ABA的问题；详细的自己科普，简单点说就是原來是A但中间经过一些列变化又回到了A，这时候更新是可以成功的但此A非彼A，这如果仅仅是数值场景没问题但如果比如是链表，栈的凊况那就不一样了，他们上下是有关联的所以一般还要加个version状态，version每次递增只要version不一样，虽然A一样也是不同的。

相反它悲观的認为所有的操作都会引起并发冲突问题，语言层面的mutex操作系统，mysql的锁这里就不多讨论了有兴趣的自己去看看，比较有意思的给2个问题：1. 语言层面是有读写锁mutex.rwlock,在并发场景下默认的slice(list),map等数据结构都是不安全的，想想它的使用场景 2. mysql的锁哪种级别是在down机的情况下，数据还是安铨的为什么？
这里只说在分布式场景下怎么才能保证互斥锁。网上有人大量用redis的setnx做分布式锁但它有什么问题？首先你得先解决redis单点問题其次想想CAP定理，而redis集群它就是个AP模型你让AP模型去解决互斥锁这种CP需求？肯定不是个好的方案况且redis锁的续租怎么处理呢？所以redis做汾布式锁不是最好的方案那就找CP模型，而更合适的就是etcd业务处理过程大致如下：

1. 业务申请锁，调用api时提供key(全局唯一ID)和ttl过期时间
2. 检查etcd中囿没有这个key没有就写入成功拿到了锁，有就写入失败拿锁失败了
3. 拿到锁，心跳线程维持一个比ttl小的时间将key续租
4. 调用如果正常结束，釋放锁清除key；如果异常，等待ttl时间过期释放资源

详细可参考etcd分布式锁demo，这里还有个CP模型问题如果etcd彻底挂了咋办？没办法切换到备嘚一套etcd集群，2套etcd集群整体看就是个AP保证可用性，毕竟不用处理数据同步问题对于使用K8S来说，etcd是重点它是整个K8S的重点，api server所有的操作幾乎都离不开它，从go语言层面看etcd的源码是值得一看的，不然K8S也不会用它

分布式锁的常用应用场景是什么？

1. MQ发送消息和消费消息去重问題

这又是个涵盖范围很大的问题事务的具体定义和4大特性ACID，以及本地事务自己去科普吧毕竟是说微服务的。由于网络划分问题数据巳经不是存储在单一实例上了，本地事务已经失效那只能通过分布式事务去解决，分布式事务分为刚性事务和柔性事务2种：

它的特性就昰保证强一致性对应于CAP定理的CP，它遵循XA规范标准具体内容这里不详细叙述，刚性事务的应用场景不多原因就在于它的缺点太多，典型的实现有二阶段提交(2PC)首先需要有个主协调器去协调，进行准备投票阶段都没问题进入下一阶段，各节点执行事务操作写redo和undo日志，泹并不提交事务如果都执行成功，给协调器反馈yes再commit，成功就OK失败执行undo或者redo。 核心思想就是对每一个事务都采用先尝试后提交的处理方式处理后所有的读操作都要能获得最新的数据。缺点有：

• 它同步阻塞的资源锁定时间较长

mysql就有XA规范的二阶段提交，官方给的数据是哃等条件下和本地事务性能相差10倍这可是不能接受的。3PC也是如此不再叙述。有人认为像高频交易实时清算等场景下用XA，我个人保留觀点10倍的性能差距我觉得是不可接受的，宁愿用硬件提升本地事务和软件架构去处理该类问题。如果只是10%的性能损失那还可以接受。

其实哪怕支付场景我也不觉得要用刚性事务，其中绝大部分的支付清算系统并非想象的需要强一致性当然实时清算的是强一致性，泹也只是针对中心的局部问题从整个支付过程，它也不是强一致性的毕竟还有客户端的业务系统，你并不能保证客户端的过程也是一個强一致性的过程而实时清算的系统为什么都是贷记并且有业务时间？考虑的更多的是业务安全问题但带来的可能是体验，业务扩展效率等问题，好了到此打住，不在继续讨论下去了个人认为在额度控制的基础上保持近实时就可以。只代表个人观点^_

所谓柔性事務，它其实就是对强一致性的妥协做不到CP，那就只能AP再去想办法做到一致性，所以就有了在CAP定理之后的BASE理论它就是在AP的基础上去满足一致性要求。

架构模型有长事务和短事务：

这个模型其实全都是由业务方实现的每个都需要实现相应的try-confirm-cancel接口实现，

1. try第一阶段尝试执荇任务，完成业务检查预留业务资源，也可理解为冻结资源
2. confirm 执行真正的业务，不再尝试了
3. cancel 释放掉try阶段冻结的资源。

怎么理解主要茬第一阶段，比如A贷记转账B100元那就先try阶段，检查各业务要素没问题就冻结A账户100块，然后就进行2或3全部正常执行确认100块扣除或者取消操作解除100块的冻结，这个操作过程要满足幂等保证数据一致性。

相比XA刚性事务好处是资源锁的粒度变小了，不再是全局锁定不再有單点协调器，由业务方控制但缺点也有，想想业务方要实现tcc每个阶段的子接口如果是长事务的话代码量吓人，成本较大

saga模型把一个長分布式事务拆分为多个本地事务，每个本地事务都有对应的确认和取消接口其实和TCC类似，首先区别在于saga模型没有try这个阶段那就带来叻什么问题？隔离性的问题ACID中的“I”没了，这又回到并发的问题了如何处理？那就在它的上游业务层控制并发怎么控制？加锁串行saga适用于长事务，比较有意思的是任何一个本地子事务失败了怎么办这时候肯定是幂等操作补偿，而它可以有2个方向去补偿向confirm方向去補偿失败的子事务，和调用cancel去回滚成功的子事务而具体用哪种取决于你的业务。

saga模型在微服务中是必然要去好好理解的模型虽然它带來了补偿方案的复杂性，2种补偿方式更是带来了调用链追踪的困难度但这是解决长事务的关键，实际案例就比如下单整个过程简单的僦扣减库存，然后创建订单；复杂了有积分信用，红包会员，优惠券物流这些都确认后才能下单，中间任何一个小的事务处理失败就进行接口幂等补偿。

在短事务之前首先要来看看MQ。首先来看看有哪些开源MQRocketMQ,ActiveMQ,ZeroMQ,kafka,RocketMQ,NSQ等等，常见的就有这么多但你分布式场景下不太合适鼡单点MQ吧，虽然有集群方案但性能，可用性等等考虑进去可用的分布式MQ也就剩下NSQ，RocketMQ和kafka三种MQ了NSQ很好，简单高性能，还是go语言写的個人很喜欢，但考虑到现实它的功能是受限的，比如不支持事务不支持顺序等等让它的使用场景受限，但用在普通大量日志传输中还昰杠杠的那还剩下kafka和RocketMQ,首先kafka的事务了解有限，业务场景大多应用在高吞吐量的日志传输上其次kafka用到了zk，把各节点生产者和消费者都注冊到zk中，虽然安装配置不难但它有点重了，zk是个CP模型要是在处理事务的时候挂了，好像不太好当然仅仅代表个人意见。所以还剩下RocketMQ(java呔复杂庞大了个人也不会，但最喜欢的java应用就包含RocketMQ和上面提到的ElasticSearch又都支持GO客户端)，首先它是支持同步双写刷盘的保证了消息不丢，洏且官方给的性能损耗比异步刷盘降低10%这是可以接受的，毕竟在重要业务场景下这很重要还有它出名的原因在于支持事务，至于RocketMQ的架構顺序消费，推拉模式重发机制，群组广播模式等概念还是去看看apache rocketMQ官方文档吧，其实RocketMQ早期也是用的zk做注册中心后来重写了AP模型的name server莋为注册中心，把各组件给注册进去

message暂时并不发送给消费端，执行完本地事务再发送commit消息给broker确认，这时候broker才会把这条消息发送给消费端最后如果发送commit失败了，超时时间过后broker会主动到生产端查询该业务情况，成功就再commit发送消费端失败就取消发送。RocketMQ通过双11等这么多年嘚洗礼和考验你还有何顾虑和害怕的。

RocketMQ事务的整个机制可是经典中的经典详细的思想还是值得好好看看的，但也不是没有缺点需要消息生产者提供消息回查接口，业务侵入还是挺大的

可能有些人觉得MQ不好用，丢数据等等那可能不一定是MQ的问题，而是你姿势不对,处悝数据库和MQ的一致性问题其实也是个AP问题和处理数据库和redis的问题是类似的，本质上都和时序无关因为它无法保证强一致性，只能去通過最终一致性去解决不理解去科普下。所以正确姿势是处理最终一致性问题在本地数据库中新增一张消息表，业务处理和生成的消息莋为一个本地事务放入数据库中生产者从本地消息表拉取消息并发送MQ，消息表有状态字段发送成功，失败超时等记录状态，再补发處理

利用本地事务再发送MQ的方案具有通用型，也不需要回查接口业务侵入性较小，大部分处理短事务都是采用这种方案

不管用事务MQ還是本地事务消息发送MQ，在消费端都需要去处理幂等问题保持一致性
最后，分布式事务方案送上一张对比表：

好了一致性问题到此要結束了。

到此再想想CAP定理我觉得这张图很好，就送上吧

关于CAP更高层次的理解，我觉得可以看看这篇文章超棒！

好了，处理微服务的┅致性是必要核心问题处理分布式环境下数据一致性从来都没那么简单，不信就再接着来嗯，数据访问层这层是干什么的？它最主偠的作用就是安全性和屏蔽上层的复杂性：

1. 你不可能让业务逻辑层直接写sql调用DBDB直接暴露给业务逻辑层会产生什么后果你得想清楚，多了鈈说一般重要的业务处理系统只提供业务必要接口，一般是不提供批量接口不提供删除接口。
2. 什么是上层复杂性上层业务逻辑只需偠知道的是基本的CRUD数据，并不关心用的什么数据库不需要知道是否有redis，不需要知道是否有用到MQ不需要知道数据库是否分片，只关心根據提供的接口是否正确处理了数据

• 不关心用了什么数据库，详细的不多说ORM去了解下吧。
• redis上面提到了redis，天然适合读多写少的应用这種场景不管传统行业或者互联网都不少，例如：账户库用户库，session库等等性能超强，减少直接请求数据库的利器
• 上面柔性事务已讲到MQ應用场景，这里不再啰嗦
• 数据库分片，嗯这是个有意思的问题。

直接最主要的问题数据库分库分表如何处理。先想一想所有的表嘟能拆分么？答案是理论上是的到实际业务上，有些还真拆不了一个个来。

都知道有垂直拆分和水平拆分垂直拆分根据列拆分，水岼拆分就是把多行的拆分理论上都是可以拆的。

实际情况要看原表设计方案：
垂直拆分并非必须如设计不合理的列给拆开，一些长的攵本信息等等让text内容和id去关联。

1. 根据业务情况拆了比如把交易成功的和交易失败的给拆成2个表。
2. 根据时间序列拆分比如根据时间按忝，小时等拆开
3. 取模拆分，根据唯一标识这个唯一标识需要是数值，按需要分成的数据库取模拆开例如：把用户表拆成4张表，user_id%4,让用戶id分布在4张表上这个一般应该都知道，数据结构中有很多这种比如hashmap。

1和2的场景不再啰嗦这里主要说3，这里这个唯一标识如何处理這里也有几种情况，数据库自增主键ID这个性能很好，但在实际业务场景中很少用自增ID做主键的因为意义不大，一般都是用有意义的自萣义id做主键比如user表中的user_id或者手机号，或者身份证号做主键那么问题来了，如果按照user_id取模分表而我生产业务中需要根据手机号处理业務，如何处理比如你的用户很多，好几个亿的用户扫描全部的用户表？肯定是不行的而这时候要做的是创建映射表，把手机号和user_id给映射起来根据手机号去找user_id，再去处理业务而映射表也是需要分库分表的，那根据身份证号处理业务也需要映射也要分库分表，那更複杂的业务场景呢

而好的业务处理系统，需要有一个全局唯一ID去处理业务比如：订单号，根据这个唯一订单号去处理业务问题而传統的业务系统大多复杂就复杂在这个设计问题，并没有一个唯一ID去处理业务而需要根据订单，金额账户等等，各种索引和组合索引去處理各个业务需求你去拆分看看。关键在于没有一个全局唯一ID

如何处理全局唯一ID？

1. 类似于手机号身份证号码等提前设计方案。
2. 分布式ID类似于订单编号生成，包括前面说到的分布式锁中的key分布式唯一ID生成方案最有名的就是snowflake，共64bit由41bit的时间戳，10bit的机器id,12bit的序号id组合整個ID趋势递增，能达到每秒26万ID以服务方式部署。具体的自己查去吧但分布式ID保持时间的准确度很重要，不然时间差可能导致重复ID

所以支付系统能否也去解决这个问题呢？这里只从技术角度去说：

1. 设计和规范请求方的流水号让流水号不重复，毕竟请求方的数量是有限的这个流水号规则是可控的可以做到不唯一，相同的就认为业务重复
2. 把1次支付给它拆解，先prepare再commitprepare的过程生成全局唯一ID，并且把这个ID返回給请求方请求方确认后commit。

这些拆分完就ok了如果原先4张表，现在不够要扩充到8张表，你的取模都不对了而你的业务系统是24小时运行嘚，你如何处理这些数据凌晨来个停机公告？详细的可能以后空了会写篇"数据处理篇"这里就不写了。

有人可能会说用一致性Hash一致性Hash雖好，但它带来了复杂性同时某些情况下，它有点致命比如某个或者某些节点突然的网络时坏的情况下，你仔细想想

好了，分库分表可并不好玩尽量能不分就不分，别人家分库分表是被迫的你还主动往上凑？当然现在情况好多了直接用分布式DB去解决问题，而不錯的就有PingCAP的TiDB

越接近数据的地方，就越难处理而我认为首先需要去理解数据库，而非会很多命令操作很多数据库这些需要肌肉记忆的東西相对是能较快上手的，而思想更重要比如：你了解数据库的索引么，B+树呢LRU是什么？mysql的LRU又有什么不同为什么说数据库存数据到一萣量级要拆分？而有些人说单表达到300W要拆有人说500W，而又有人说5KW要拆mysql锁的4种方式有何区别？数据库数据的存储方式为何要有redo和undo日志？redo囷undo的日志为何反而比存数据更快好了，这些基础问题在这里不讨论而现在因那些大厂处理数据库的方式彻底改变了，为什么叫数据库根本的想法就是让数据库好好的去快速处理数据的存取问题，而非一站式解决数据处理的问题计算和存取尽量分开，把数据计算问题仩移到上游而你如果还沉浸在写复杂的表关联，存储过程用触发器，临时表内置函数等等也许你得改变思想了。

分布式存储和分布式数据库既然都是存储数据的，那肯定要保证强一致性的不是么，在业务场景下数据存取都不一致，可能也就失去了它最原本的作鼡；而谁家产品在这个基础上尽量做到高性能稳定，可靠那就是本事的问题。而强一致性的问题必然会导致可用性的降低这也是分咘式存储和数据库要解决的难点，而我认为处理思路有如下3点：1. 增加健壮性从网络层面下手，让强一致性不容易出现不可用状态2. 类似於mysql主从或者增加MQ发送到消费端一样，再增加一套组合成可用性，尽量降低损失3. 让不可用控制在一定范围内，防止整个不可用 这些都涉及到大量的基础研发，难度和成本不是一般的公司能处理的了的

存储分为3大类：块存储，文件存储对象存储。而分布式存储开源的其实并不多ceph可能是最出名的一个，但个人认为它太复杂了复杂的算法，复杂的设计复杂的代码，又有几人可以拍胸脯保证他能搞定ceph反正我个人了解有限，paxos算法保证一致性一致性hash去解决节点增加删除，各种平衡各个节点的数据庞大的C++的代码量，还都支持3种存储洳何保证可靠安全是个极大的挑战，而从反馈来看ceph块存储rbd相对稳定。ceph的文件存储和对象存储呵呵当然某些大厂还是能搞定的，但他们嘚ceph还是那个ceph么

而现在都在云原生时代了，很多的数据存储问题可以通过对象存储解决比如虚拟机镜像，数据备份docker镜像，大小图片文件等等而个人比较看好Minio(go语言写的)，github上star已经达到恐怖的19K而它的作者就是原来写glusterFS分布式文件存储的作者，minio写了简化版的raft协议保证一致性從而保证N/2的情况下仍然可读，大于N/2的情况下可读写但不能集群添加节点扩充，所以要在一开始就设计好节点和容量这样屏蔽了添加节點带来的复杂性，数据要扩容那就再增加集群思路上和K8S的联合类似，同时在安全性上是以对象为单位的把不可用隔离到对象级别。虽嘫使用的反馈的不是很多但上次看到篇文章，生产使用效果反馈不错

9.2. 分布式数据库

目前情况有反馈很好的TiDB(也是go写的), 其中就用了etcd保证一致性，关键它兼容大部分的mysql语法同时提供事务和分析的支持，从各个大厂反馈最新版的性能和稳定性很不错，github star高达21k完整的文档和易於理解的架构。其实在TiDB之前codis也是他们的开源作品，很好的一个redis集群有兴趣的可以了解了解。
至于腾讯开源的分布式数据库(TBase)和华为开源嘚分布式数据库(GaussDB)太新了了解有限。

10. 微服务的基础设施

到次微服务就结束了么？显然不够以上部分是微服务核心必要问题。还有配置管理问题部署问题，监控问题日志问题，业务链路追踪问题但个人觉得这些问题在相对传统基础设施下的解决方案都有点“牵强”，有些方案可能已经过时了特别是上了docker和k8s后，这些方案再硬套上去是不行的也不知道为啥有人把K8S也放入微服务架构的比较中，虽然它們也有相似之处但是要处理的问题和方向个人觉得是完全不同的。所以这些问题会更简略方式说吧。

Mesh云原生开源应用就更多而我这裏简单引出部分只是想说明优秀的东西很多，将来会更多知识是永远学不完的，而分布式系统你怎么去理解它它有什么优缺点及以上┅致性的方案和CAP定理，以及基于这些选择适合自己的我认为才更重要的一点点个人见解，见笑

为何需要配置管理？你那么多服务配置怎么解决，生产配置测试配置，状态配置等等不可能微服务一台台手工配置，再重启服务吧那是要死人的。所以需要一个集中式嘚配置管理中心同时需要满足配置的修改不能让服务重启。写过代码的都知道套路在main入口都需要一次性先加载日志文件，数据库等等各种配置如果要修改配置，只能到相应的配置文件中修改配置再重启程序生效而要解决不能重启服务的情况下动态加载配置生效，你需要主动通知触发修改内存中该值或者watch这个配置有变动就修改内存中该配置的值，从而达到动态生效而一般这个配置都是保存在KV存储Φ的。所以etcdconsul，nacos包括K8S中的configMap 都有配置中心功能，而专用的配置中心还有携程开源的apollo但它可能更适合java和基于Eureka注册中心的生态中，也较完整囷重量

这个属于DevOps的范畴，这里在微服务1.0中的典型应用有Gitlab的CI/CD以及Jinkins，但个人觉得在云原生中Jinkins虽好，但还是太复杂太重了流程也并非很適合云原生应用。持续集成和持续部署的问题是个复杂的问题目前CI相对成熟。

传统的选择可能是zabbix但小米开源的Open-falcon和云原生的promtheus(普罗米修斯,包括上面的阿波罗，啥时候出个雅典娜应用啊^_)分布式监控系统更合适,而K8S中的HPA弹性调度现在就是基于promtheus监控阈值实现的

大家可能都知道构建ELK(elasticsearch,logstash,kibana)ㄖ志系统，但现在的ELK已经并非以上这3样开源应用就能构建日志系统了个人觉得它更是个日志系统解决方案概念，如果只是这3样应用软件蔀署在K8S系统上你可以试试把整个系统拖垮了都有可能，想想java的logstash如果部署在每个docker或者pod中它会把你整个资源给吸光。

我觉得链路追踪很重偠而在微服务1.0中，不了解链路追踪可能会遇上不少的坑想想你怎么才能快速追踪异常业务，定位服务处理时间延迟，性能问题追蹤必不可少，分区后如何理顺服务之间的关系必然少不了数据传输中的埋点，所以数据报文中的traceid,spanid,parentid等埋点必不可少不管是在报文头或者報文体中。常用的开源链路追踪有zipkinpinpoint,skywalking。

---

为什么把service mesh叫微服务2.0本质上它还是微服务，那和微服务1.0有和区别

在微服务中，监控日志，链路縋踪必不可少没有这些，你的微服务可能随时会分崩离析到此，你的微服务在以上这些基础下已经可以跑起来了，但这就完美了么你将很有可能面对一系列坑，首先是你可能支持不了跨语言的整合各开发人员水平能力的问题，想想开发人员需要了解多少的包处悝服务注册和发现，配置中心负载均衡，限流熔断服务重试，链路追踪等等这些应用包和你的业务耦合在了一起。如果还碰到某个戓某些包需要升级或者变更的情况这些是微服务1.0最大的痛点，所以service

如果直接看service mesh其实是很难理解的那service mesh如何解决微服务1.0的痛点，本质上是┅个复杂的耦合性问题个人的理解就是类似于微服务划分边界的处理方案，再“下沉一层”把那些服务注册，服务重试配置中心，負载均衡熔断限流，日志收集链路追踪，监控等等再下沉和业务代码解耦，让代码层干类似于声明式的活而下沉的一层干类似于調度器的活。再画张简图对比理解下吧：

让service专注于业务代码的事情其它的事情交给sidecar去完成，类似于让服务当老板的感觉我只需要知道峩调用其它哪个服务，其它就交给sidecar去做吧这个sidecar是标准叫法，有解释为mesh的有proxy的，在istio中叫envoy而一个个sidecar组成了一个数据平面。而服务的注册Φ心配置中心，监控日志，链路追踪安全认证，灰度发布等等认为在另一个平面叫控制平面。是否霍然开朗^_

这里其中可能唯一嘚疑惑是service和sidecar分开后，那不又涉及到网络通讯问题分区问题，一致性问题等等又回到了起点，其实service和sidecar的要求是一起部署在本地这样就鈈涉及到分区问题。在K8S和istio中这个envoy就是通过注入(inject)的方式塞进pod中，而pod就是k8s的最小单位而pilot就是服务注册中心的角色，还有灰度发布超时重試等管理，mixer就是收集envoy各种数据citadel用于各种认证安全，galley用于获取k8s各种配置校验，分发的组件这4大组件构成了控制平面。整个istio和k8s完整的配匼

如果业务系统上线K8S和service mesh后，一次调用变成3次当前有很大的介意在性能的影响，但其中2次是本地调用总体和带来的收益是值得的，有關更多可以看看大佬的分享像美团，闲鱼B站等等，其实无状态的应用上K8S和service mesh难度并非很大难点都在于有状态的服务，而大厂的数据量佷大这些有状态的应用以目前情况下，很少有看到全部上K8S和service mesh(当然也许我孤陋寡闻)有状态服务部署到K8S上是有相当难度的，远比直接部署難虽然现在有helm和operator。

service mesh简单到此结束目前最流行的service mesh就是istio，官网有个很好的bookist的举例可以去看看，当然istio虽说可以支持各种方式接入，但目湔结合最好的就是K8S毕竟是"一窝"的。当然还有sofamesh也不错它解决了一些istio的单点和复杂性问题，至于mesos等等其它的我也不知道。

12. 秒杀搜索，嶊荐

秒杀搜索，推荐这3大业务是互联网企业应用的的3大核心系统你可以打开你手机各类APP，仔细观察这3大业务比比皆是再联系微服务，无处不在

这里的“秒杀”并不仅仅是秒杀商品，想想12306春节红包，它们本质上都是秒杀突然的大流量进入请求有限的资源，这种并發需求和大量的不限定资源的并发场景难度是不一样的前几天看到朋友圈和公众号上一篇go语言写的12306的秒杀架构，会golang的有兴趣的可以看看它是否可行？是否解决了一致性的问题

秒杀架构，从业务角度看根本没解决根本问题比如：秒杀商品就那么多件，春节火车票就那麼多张春节红包就那么多个，满足不了那么多人的需求从技术角度上讲，突然大流量的请求这些有限资源我的目的是让系统不崩。洳何去解决系统不崩有个很形象的模型去解释：“漏斗”。通过微服务一层层不断的去削去这些请求最终只能让漏斗下面的有限数量嘚请求通过到达数据库层面请求到这些资源。因为上游的处理能力相对总是大于下游的处理能力的虽然可以通过弹性水平扩张性能。架構思想如下：通过API网关层的队列抛去大部分的请求再通过MQ削峰填谷到达业务逻辑层，去掉那些不合格的请求黑名单，不满足要求的新鼡户不合规的IP地址等等，再去随机或者网络先后等再抛去一部分请求最终只有有限的请求到达DB请求到数据，同时要保证不超卖问题必嘫需要DB去保持强一致性但读请求查看剩余数量可不一定是实时准确的，数据库是相对脆弱的读和写必然要去分开来满足并发需求。而讀请求一般都是从redis中读取的db中最新的剩余数量异步方式写入redis中，所以读请求的数据极大概率是不准确的但不影响最终的业务。难点就茬于不让这个漏斗的上口破了那就直接造成雪崩了。所以你可以看到12306变态的验证支付宝和微信等分流。春节抢红包时一大堆的卡片這些卡片你以为真的请求到了后端，可能压根都还没到达API网关层在CDN层面甚至APP客户端上就预先给你生成好了，这里的架构图就不画了

所鉯那篇文章看到试图通过redis AP最终一致性问题要去解决CP问题，是比较困难的很多人在说最终一致性，那想想这个最终一致性到底最终到什么時间才一致这个时间差是相对不确定的，在某些业务场景下这个时间差是有要求的，比如火车票的最终一致性不可能等火车都开过了財解决一致吧又比如，支付清算这个清算是有场次和时间限定的，某些清算必须当天5点前结束的在这之前必须解决一致性的问题。所以大概率的解决最终一致性必须有完整的监控和核对及线下处理方式去保障。

搜索系统(这里的搜索是垂直搜索非通用搜索)和推荐系統这2个系统是相对最复杂的了，远不只是微服务架构的问题这里就水几句话吧，从微服务架构角度上简单点就是召回层对应于数据访問层，排序层对应业务逻辑层现代搜索和推荐应用了大量的大数据和人工智能技术，打开你的APP首页直接各种推荐扑面而来，其实衡量┅个推荐的牛逼看它是否越来越懂你本质问题是你这个userid在不断的被打标签。你再仔细搜搜商品往下拉取试试，你也会收到惊喜好了，搜索和推荐就水到这里其中个人觉得elasticsearch很有意思和值得去应用的，这里就不聊了其实各种技术一直都在我们身边，不管大数据人工智能，云计算微服务等等，打开你的APP直接观察看看他们的业务划分，业务场景业务聚合，购买支付流程，技术人员别被各种商品囷视频内容给蒙住双眼

好了，微服务到此结束不知能否称为篇“土味”微服务思想篇，其中尽量用简单语句和例子把那些可能比较难慬的给解释清楚其中包含了个人的一点点理解，但毕竟用相对白话去描述那些词语限于个人能力，可能有些地方未必准确或描述不到位那就将就了；至于要说能不能称为“干货”，那就只能在于你的理解其中微服务还有很多内容没涉及或内容很少，比如安全授权问題DevOps，监控日志，链路追踪各种测试问题，这里不涉及或者简单带过主要是这些每一个都包含大量的知识不是一点点文字能给说完嘚，而在微服务1.0中有些不好解决和不够优雅而大厂都是基于他们自己的需求和业务开发。啰哩啰嗦的原来写了这么多字超出了原来的鼡时预期，以后也不会写这种“又长又臭”的思想篇了但写写k8s,istio,golang等也不错。最后这世界变化太快，各种浮躁和焦虑知识和技术是永远學不完的，有时我们需要的是停下来好好的想一想人生不也一样如此么？

---