zyq025的专栏

别慌，名词都是搞来吓人的~~~

用起来真舒服~~~

SkyWalking配上告警的确给力，但好像更慌了；

SkyWalking 让你不迷路

前言在真实的项目中，不管是功能日志、错误日志还是异常日志，已经是项目的重要组成部分。在原始的单体架构，通常看日志的方式简单粗暴，直接登录到服务器，把日志文件拷贝下来进行分析；而如今分布式、微服务架构盛行，如果每个节点服务器都去拷贝一次，估计还没等你拷贝完，Boss就要炸锅了；特别是遇到线上问题，肯定需要快速响应，所以好的日志管理工具真的不能少，这里就来说说Excetpionless日志框架。正文1. Exceptionless简介Exceptionless是开源的，可以为http://AS.

前言关于前面系列的文章已经说到分布式服务之间的通信，则分布式事务接下来就是我们要一起学习的主题，走起。数据库事务在现有大大小小的系统中几乎是避免不开的，或多或少总会有一些业务关联在一块；对于单机事务的应用场景和操作，相信小伙伴已经够熟练了；随着分布式、微服务的开发模式普及，分布式事务落地也成为了程序员的必备之技，接下来的几篇一起来学习和实操。正文1. 事务回顾1. 1 事务简介通俗一点理解就是将一组对数据的操作(增、删、改、查)看做成一个逻辑单元，要么都执行，要么都不执行，确保数据一

前言上一篇对gRPC进行简单介绍，并通过示例体验了一下开发过程。接下来说说实际开发常用功能，如：gRPC的四种模式、gRPC集成JWT做认证和授权等。正文1. gRPC四种模式服务以下案例演示，服务端用微软提供的模板创建，客户端使用Winform程序演示，基于.NetCore3.1版本。具体创建步骤在上一篇说的很细了(gRPC趁现在还没大火，抢先了解一下)，接下来就直接搞重点；这里就模仿一个学生服务，包含增、删、改、查方法，下面是用到的proto文件的全部内容，后续的实例就单独标出重点即可。

前言系统分布式已经成为程序员的家常，将大型单体划分为相对简单的小模块，分散系统能力，提升系统扩展性、功能模块复用性等；各功能模块之间肯定会有很多数据共享和交互的应用场景，那就避免不了各模块之间的通信；目前用的比较多的方式是HTTP（Restful API）接口、消息队列等，而HTTP（Restful API）接口应该是目前应用比较广泛的，相对之前的webservice和WCF都显得比较轻量级，而且实用；随着微服务的盛行，对服务间的通信要求也越来越高，比如传输方式、传输速率、传输内容大小等，而HTTP

前言关于网关(Ocelot)的分享，还遗留一些功能没演示呢，接着来聊聊；这次重点针对网关Ocelot使用缓存、集成Polly做服务治理、集成IdentityServer4做认证授权来详细说说；如果对上一篇感兴趣，点这里(网关Ocelot功能演示安排的明明白白~~~)。正文1. 使用缓存Ocelot中的缓存是对下游请求结果进行缓存处理，多次请求下游API时，在有效期内就可以从缓存中获取，提升服务性能。以下演示代码还是接着上一次代码举例的，代码地址为：https://github.com/z

前言网关(Gateway)在微服务架构中至关重要，可以将其理解为是外部客户端(前端、MVC后台等调用方)与后台服务的连接点，通过这层可以做统一的处理，比如路由、身份认证和授权、服务治理等；网关的好处：统一入口，调用方(客户端)不在为调哪个服务而头大，统一入口即可，由网关路由到对应后台服务； 统一处理公共逻辑，比如认证和授权，避免相同逻辑多处实现，易于维护； 对后台服务可以做负载均衡，根据指定的负载算法找到合适的后台服务调用，而这些细节调用方都不用理会，只管调就行啦； 初步过滤非法请求，可以

前言上一篇简单介绍了Consul，并使用开发模式（dev）进行流程演示，但在实际开发中需要考虑Consul的高可用和操作安全性，所以接着来聊聊集群和ACL的相关配置，涉及到的命令会在环境搭建过程中详细介绍。正文关于集群，第一反应就是多搞几台机器(或者容器等)，将其关联在一块，提供功能即可；在搭建集群环境之前，需要对几个角色进行熟悉，因为在Consul中，它们至关重要。见下图(以一个数据中心为例)：数据中心(DataCenter)：Consul运行的节点集连接在一起称为数据中心..

前言在微服务架构中，对于一个系统，会划分出多个微服务，而且都是独立开发、独立部署，最后聚合在一起形成一个系统提供服务。当服务数量增多时，这些小服务怎么管理？调用方又怎么能确定服务的IP和端口？服务挂掉了又怎么办？单靠人工处理已经不太现实，使用系统统一管理就是最好的选择，常用的服务发现产品有：Consul、Zookeeper、Etcd、Eureka等，而对于Consul在.NetCore中是很火很火的，所以接下来肯定先聊它喽。正文Consul是一个支持多数据中心、分布式、高可用的服务发现和配置共享

前言原计划打算在春节期间多分享几篇技术文章的，但到最后一篇也没出，偷懒了吗？算是吧，过程是这样的：每次拿出电脑，在孩姥姥家的院子总有阳光沐浴，看不清屏幕，回屋又有点冷(在强行找理由)，于是又带着娃遛弯去啦。哪有那么多理由，就是想偷个懒；不过后面几天把计算机组成原理简单过了过，后面整理整理再单独给小伙伴分享吧。这次接着IdentityServer4说，之前一直用内存数据进行测试演示，在正式项目中肯定是要存数据库的(除非数据固定，用内存方式实现)；接下来就用Demo实操的过程说说IdentityServ

前言接着授权模式聊，这次说说Authorization Code(授权码)模式，熟悉的微博接入、微信接入、QQ接入都是这种方式(这里说的是oauth2.0的授权码模式)，从用户体验上来看，交互方式和Implicit没啥改变，随便找个网站瞅瞅，如慕课网(很不错的学习网站)的登录流程，见下图：但其实在代码流程上是不太一样的，接下来边撸(我说的是敲代码)边聊。正文Authorization Code(授权码)模式比Implicit多了一个授权码的流程，即用户认证成功之后，授权服务器..

前言上一篇Resource Owner Password Credentials模式虽然有用户参与，但对于非信任的第三方的来说，使用这种模式是有风险的，所以相对用的不多；这里接着说说implicit隐式模式，这种模式比较适合于纯前端客户端，比如Vue、Angular、React项目等，相对来说整个流程比较安全，只需在认证服务器进行认证即可，无需在客户端进行相关隐私信息录入，但前提是要客户端保证安全，不然容易被别人钓鱼(安全很重要)，那IdentityServer4不背这个锅。正文既然有用户参与，

前言接着IdentityServer4的授权模式继续聊，这篇来说说 Resource Owner Password Credentials授权模式，这种模式在实际应用场景中使用的并不多，只怪其太开放啦，直接在客户端上拿着用户名和密码就去授权服务器获取AccessToken，这样容易被客户端拿着用户名和密码搞坏事；接下来就详细说说。正文Resource Owner Password Credentials授权模式与上一节说到的客户端凭据模式不同，这是有用户参与的，用户就是资源拥有者；通过允许在客户

前言API裸奔是绝对不允许滴，之前专门针对这块分享了jwt的解决方案(WebApi接口裸奔有风险)；那如果是微服务，又怎么解决呢？每一个服务都加认证授权也可以解决问题，只是显得认证授权这块冗余，重复在搞事情；IT大佬肯定容忍不了，对于微服务架构，统一的认证授权中心那是必须的。随着.NetCore的发布，IdentityServer4随之而出，是.NetFoundation的成员之一，专门针对.NetCore而出的认证授权框架，当前.Net圈是比较火的啦；再配上微服务认证授权的必要性，我决定以此开始.

前言上一篇对微服的演变、优缺点进行了概述，对于业务复杂项目，微服务算是比较合适的解决方案；对于咱们开发者来说，有好的解决方案肯定要跟进学习，但不能盲目追崇流行技术，目的还是为了解决问题。这里就把Asp.NetCore落地微服务架构技术栈汇总一下(当然不限于此)，同时制定了个学习分享计划，和小伙们一起共勉；正文将涉及的技术栈将其分为如下几个阶段进行归类，后续学习分享的大方向也是如此：对于需求阶段业务分析、测试阶段相关及最后应用阶段的服务，这系列暂时就先不涉及，而...

前言微服务在编程圈火的是不行不行的啦，可能还有很多小伙伴还没有进行微服务实操，但这个词，要说没听过、没看过，那小伙伴一定是假Programmer。虽然微服务很火，但不能盲目使用；先不说涉及技术和工具有多少，首先应该针对业务需求和开发团队有一个规划，评估业务需求的复杂度和开发团队人数及技术能力。对于微服务本身，业务的划分、开发的技能、部署的方案、维护的成本每一项都不能缺，否则很大一种可能就是以失败告终。来，小伙伴们一起聊聊，我先来说说我的理解，小伙伴可以评论，私聊都行.....正文微服务的