Steve Lee

摘要： 一致性：很多时候表现在IT系统中，通常在分布式系统中，必须（或最终）为多个节点的数据保持一致。世间万物，也有存在相同的特征或相似，比如儿时的双胞胎，一批工厂流水线的产品，当然，我们不去讨论非IT以外的知识点。 注：我们一定要明白一个词叫“信息不对称”，不论是人、事、物，信息不对称是永远都存在的，要知道，在IT系统中，能引起信息不对称的因素有很多，比如网络上，有丢包、有延迟。硬件上，有不同性能的计算能力和处理能力。 在传统的IT时代，一致性通常是指强一致性，比如一个单体的WEB程序中，从数据库到缓存，再到呈现出来的界面，数据均是相同的； 而在现在的互联网时代，特别是分布式架构下，一致性的含义远远超出她原有的含义，由于互联网的特点，信息量巨大，每个人（或者不同的每个业务）获取到的信息不对称，最终都会造成不一致。 换句话说，传统的单体应用无法满足巨大的信息量，而转向为多节点、多服务的 阅读全文

摘要： 当一个APM或一个日志中心实际部署在生产环境中时，是有点力不从心的。比如如下场景分析的问题：从APM上说，知道某个节点出现异常，或延迟过过高，却不能及时知道日志反馈情况，总不可能去相应的节点上一个一个的翻日志文件吧。从日志中心上说（特别是Exceptionless，能及时反馈出异常信息），知道某个节点出现异常日志，可不知道引起异常的源头在哪；或者出现延迟过高日志，却不能及时知道节点问题，还是链路问题；就算诸上问题都能应付，那么一行行的、一个个的日志文件和使用图形化的表述形式，谁会更加直观，当然，你说你可以一目十行，甚至百行来分析日志，那我挺佩服你的。 阅读全文

摘要： 日志，一直以来都是开发人员和运维人员最关心的问题。开发人员可通过日志记录来协助问题定位，运维人员可通过日志发现系统隐患，故障等定位问题。如果你的系统中没有日志，就像一个断了线的风筝，你永远不知道它会的落脚点（故障点）在什么地方。当然，你说你不用日志，非要用调试模式来一个一个的排查和验证问题，那这将是非常疯狂的。 阅读全文

摘要： 对于普通系统或者服务来说，一般通过打日志来进行埋点，然后再通过elk或splunk进行定位及分析问题，更有甚者直接远程服务器，直接操作查看日志，那么，随着业务越来越复杂，企业应用也进入了分布式服务化的阶段，传统的日志监控等方式无法很好达到跟踪调用、排查问题等需求，可以想象，如果你的服务节点达到有很多很多（两位数以上吧），而没有一个自动跟踪系统，那查找一个问题将成为噩梦。 阅读全文

摘要： 我们知道，Consul、Etcd、Zookeeper等等这些注册中心都有健康检查的机制，用于检查服务节点的状态，是200，还是非200。但是，这种检测是粗粒度的，她只能检测节点的健康状态，却不能检测接口的健康状态，毕竟细粒度的控制太多由业务环境支配，无法统一化和标准化。本节我们介绍如何在接口（或方法）中如何实现健康状态的检测，其实也就是对某个接口的故障保护。 阅读全文

摘要： RPC是什么，是一个协议吗？不是。确切的说它只是“远程调用”的一个名称的缩写，并不是任何规范化的协议，也不是大众都认知的协议标准，我们更多时候使用时都是创建的自定义化（例如Socket，Netty）的消息方式进行调用，相比http协议，我们省掉了不少http中无用的消息内容，例如headers消息头。本一个简单的GET请求，返回一个hello world的请求和响应，元数据就10个字节左右，但是加上headers消息头等等http的标准内容，估计会膨胀到25~30个字节 阅读全文

摘要： Ocelot是一个用.NET Core实现并且开源的API网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与Service Fabric、Butterfly Tracing集成，并且这些功能都只需要简单的配置即可完成，简单的说，Ocelot是一堆的asp.net middleware组成的一个管道。当有收到请求后会用一个RequestBuilder去创建一个HttpRequestMessage发送（或请求）到下游服务器，等下游服务器返回Response后再由一个Middleware将HttpRequestMessage映射到当前请求Context中的Response上，并返回给请求者。 阅读全文

摘要： 单论Rpc框架市场，且不论Java上的Spring Boot和Spring Cloud这样大名鼎鼎的开源框架，目前Net上的Rpc整合性框架确实并不多，我们Net程序员也要混口饭吃，不能总被Java甩掉好几条街吧。 　　言归正传，一个远程过程调用，会涉及到如下几个方面的技术点（功能）： 路由转发：当服务部署在多个节点上时，调用方需要知道自己的目标服务在什么地方。 通信协议：当管道存在，还需要在管道的两端建立处理程序（宿主），以处理管道中的数据包。DotEasy.Rpc基于DotNetty进行通信处理和协议实现。 动态生成：我们知道，基于二进制的RPC传输，每当新增接口，或修改接口，都需要生成相关协议的protobuf文件（或 thrift 文件），本框架基于protobuf-net的传输框架和Rosyln的预生成，动态生成相关的CS文件。 运行时代理：本框架采用 阅读全文

摘要： 上一篇我们简单的介绍了DotNetty通信框架，并简单的介绍了基于DotNetty实现了回路（Echo）通信过程，很简单的实现了一个点对点的通信例子。 接下来我们将对这个DEMO进行简单的修改，模拟最简单的gRPC通信的一个构造过程。 本篇很简单，只要实现了上一个demo，稍作修改，就能实现gRPC了（当然实际构建gRPC根本不会这么简单），本篇也是顺带介绍一下这几天搞出来的一个轻量级RPC开源框架，方便日后工作调用，地址：https://github.com/steveleeCN87/MicroServices.Road （还未单列出来的一个开源项目）。 阅读全文

摘要： 上一篇我们已经全面的介绍过《基于gRPC服务发现与服务治理的方案》，我们先复习一下RPC的调用过程（笔者会在这一节的几篇文章中反复的强调这个过程调用方案。服务化原理可以分为三步 1.服务端启动并且向注册中心发送服务信息，注册中心收到后会定时监控服务状态（常见心跳检测）； 2.客户端需要开始调用服务的时候，首先去注册中心获取服务信息； 3.客户端创建远程调用连接，连接后服务端返回处理信息； 阅读全文

摘要： 重温最少化集群搭建，我相信很多朋友都已经搭建出来，基于Watch机制也实现了出来，相信也有很多朋友有了自己的实现思路，但是，很多朋友有个疑问，我API和服务分离好了，怎么通过服务中心进行发现呢，这个过程是通过什么来实现的呢，本篇我们就来介绍这个“调用过程”。 本篇干货较多，没有代码，阅读请注意休息！ 阅读全文

摘要： 我们再复习一下上一篇的内容，先建立三台consul server节点，两个consul client节点，分别在每个节点上跑不同（名称不同而已）的实例。我们先通过vmware启动这五个节点，并且能成功访问这个两个client节点的实例。（具体配置可以见上一篇） 阅读全文

摘要： Consul是HashiCorp公司推出的开源工具[开源地址：https://github.com/hashicorp/consul]，用于实现分布式系统的服务发现与配置。 Consul用Golang实现，因此具有天然可移植性（支持Linux、windows和Mac OS X）；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合。 本片介绍通过五台Centos7来搭建Consul集群，借助VMware Workstation搭建，具体问题和配置可搜索一下。 阅读全文

摘要： 在软件业，AOP为Aspect Oriented Programming的缩写，意为：面向切面编程，通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。AOP是OOP的延续，是软件开发中的一个热点，也是Spring框架中的一个重要内容，是函数式编程的一种衍生范型。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。 换白话文就是：保证开闭原则的前提下，不修改某一个模块（或函数）的任何一行代码，从而实现对该模块的横向扩展。 可插拔：即使抛弃AOP，核心内容仍然可以运行，降低耦合，提高可重用。 阅读全文