业务量小于500W的时候单独一个mysql即可提供服务，再大点的时候就进行读写分离也可以应付过来。但当主从同步也扛不住的是就需要分表分库了，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。
分布式ID需满足那些条件
自从Apache Kafka 2.3.0以来，Kafka Connect和消费者特别使用的内部再平衡协议经历了几次重大变化。
再平衡协议不是一件简单的事情，有时看起来像魔术。在这篇文章中，我建议回到这个协议的基础，也就是Apache Kafka消费机制的核心。然后，我们将讨论其局限性和目前的改进。
Apache Kafka是一个基于分布式发布/订阅模式的流媒体平台。首先，称为生产者的流程将消息发送到主题中，主题由代理集群管理和存储。然后，称为消费者的流程订阅这些主题，以获取和处理发布的消息。
HTTPS 它把 HTTP 下层的传输协议由 TCP/IP 换成了 SSL/TLS，由 「“HTTP over TCP/IP”」 变成了 「“HTTP over SSL/TLS”」，让 HTTP 运行在了安全的 SSL/TLS 协议上，收发报文不再使用 「Socket API」，而是调用专门的「安全接口」。
HTTPS 是 为 HTTP 增加了「四大安全特性」；本身一个“非常简单”的协议，RFC 文档很小，只有短短的 7 页，里面规定了新的协议名“https”默认端口号 443，至于其他的什么请求 – 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。
什么是延时队列？顾名思义：首先它要具有队列的特性，再给它附加一个延迟消费队列消息的功能，也就是说可以指定队列中的消息在哪个时间点被消费。
延时队列在项目中的应用还是比较多的，尤其像电商类平台：
上边的这些场景都可以应用延时队列解决。
光学字符识别（OCR）是指电子设备（例如扫描仪或数码相机）检查纸上打印的字符，通过检测暗、亮的模式确定其形状，然后用字符识别方法将形状翻译成计算机文字的过程。百度自己的开源产品是PaddleOCR，总模型大小仅8.6M。
PaddleOCR旨在打造一套丰富、领先、且实用的OCR工具库，助力使用者训练出更好的模型，支持iOS和Android系统，功能如此齐全，难怪霸榜Github热榜：
伴着云计算的兴起，软件定义网络（SDN）技术带来了新一轮的网络技术变革。SDN技术在数据中心和云网络中的应用已非常成熟，近几年业界逐渐把焦点转向数据中心之外的广域网，希望用SDN的技术来解决传统广域网中的问题遇到的挑战。
随着企业新兴业务的爆发、迅速增长。传统以昂贵MPLS专线为主的传统广域网互联难以支撑企业WAN的流量激增，SDWAN逐渐成为企业总部分支互联在云时代的首选。
SDWAN（Software-Defined WAN）软件定义广域网技术，是以广域网设备支持虚拟化功能为基础，构建多租户的虚拟化软件网络，以及软硬一体化的网络配置、监控、调度、可视化等功能，实现按需自助、敏捷弹性、低价高效地获得广域网服务的目的。
随着物联网设备数量的持续增加，这些设备之间的通信或连接已成为一个重要的思考课题。通信对物联网来说十分常用且关键，无论是近距离无线传输技术还是移动通信技术，都影响着物联网的发展。而在通信中，通信协议尤其重要，是双方实体完成通信或服务所必须遵循的规则和约定。
这里列举一些可用的物联网通信协议，它们具有不同的性能、数据速率、覆盖范围、功率和内存，而且每一种协议都有各自的优点和或多或少的缺点。其中一些通信协议只适合小型家用电器，而其他一些通信协议则可以用于大型智慧城市项目。将物联网通信协议分为两大类，一类是接入协议，一类是通讯协议。接入协议一般负责子网内设备间的组网及通信；通讯协议主要是运行在传统互联网TCP/IP协议之上的设备通讯协议，负责设备通过互联网进行数据交换及通信。
几乎所有人都认可在智能手机之后的下一个时代属于物联网，但物联网的一些关键性业务发展上还混沌不清，比如物联网的操作系统。
随着入网设备数量的指数级增加，过去一些无法和用户产生交互的设备将产生交互需求，而由众多设备组成的集成网络也对操作系统提出了新的要求。
跨平台的操作系统在研发层面是很难的，发展的过程很大程度上也是对过去积累的不断抛弃。微软一直在追求跨平台操作系统的开发，但到目前为止也没有成功。苹果则采取的是折中的方案，或裁剪，或重写后推出了MacOS、iOS、WatchOS和TvOS这四款分别对应于电脑、手机、手表和电视的操作系统。目前的很多厂商也采用裁剪的方式推出过渡阶段的系统，比如安卓基础上裁剪出的Android Things、Win10基础上裁剪出的 Win10 IoT，以及AliOS裁剪出的AliOS Things等。
这是一个很好的问题，也是很容易混淆的一个问题。
首先总结下结论，即微服务架构下有用全部是标准化轻量Http Rest接口，因此不需要比较重的ESB总线产品来集成。但是在需要统一对外暴露能力的时候仍然需要API网关完成（可以将API网关产品理解为ESB总线个一个轻量实现）。
首先来解释下API网关。
对于非技术出身的产品经理来说，如果突然接到一个要“设计SDK”的活儿，其实并不容易。毕竟，SDK是主要面向开发者的，更像一个toD产品。那么，产品经理在设计SDK时，需要注意哪些点呢？换句话说，一款好的SDK应该具备哪些特性？本文将从“小”、“稳”、“好用”以及“安全”四个角度来具体阐述。
我们以一款好的推送SDK为例，那么首要需考虑到SDK包体的小巧灵活性。
为什么选择更小体积的包体？
对于商务人员来说，包体体积小，他们更容易接受。对于技术人员来说，他们在开发产品时，普遍追求“代码少、功能全”，这是来自程序员的代码洁癖。
那么从代码层面来看，是因为系统有“65535限制”。
A complete solution to automate processes end-to-end – with exception management, complex decision-making by humans, and delegation of repetitive task sequences to a digital workforce of software robots. [Bonita and UiPath]
一个完整的解决方案，实现了端到端的流程自动化—异常管理，由人类进行复杂的决策，并将重复性的任务工作授权给由软件机器人组成的数字化劳动力。
普罗米修斯（Prometheus）是现在重要的云原生监控平台之一，它允许企业从任何基础设施或应用组件收集和处理指标数据，用于监控容器化工作负载。它与Kubernetes和云原生生态系统中的其他组件集成，通过监控数据可以帮助企业收集和处理四种类型的指标：计数器（counter），量规（gauge），直方图（histogram）和摘要（summary）。Prometheus数据模型反映了Kubernetes基础架构元数据，使其成为Kubernetes监控的自然选择。
普罗米修斯是为大型环境设计的开源监控和警报解决方案，通常用于包含容器和容器化工作负载的环境中。它以较低的系统资源要求实现了丰富的自定义和灵活的查询。如果需要，它还可以通过一台服务器同时从数千台计算机中获取大量数据。
六边形架构的思想是将输入和输出都放在设计的边缘部分。不管我们公开的是 REST 还是 GraphQL API，也不管我们从何处获取数据——是通过数据库、通过 gRPC 还是 REST 公开的微服务 API，或者仅仅是一个简单的 CSV 文件——都不应该影响业务逻辑。
这种模式让我们能将应用程序的核心逻辑与外部的关注点隔离开来。核心逻辑隔离后，意味着我们可以轻松更改数据源的细节，而不会造成重大影响或需要在代码库重写大量代码。
另外，在应用中具有清晰边界的另一大优势就是测试策略——我们的大多数测试在验证业务逻辑时，都不需要依赖那些很容易变化的协议。
Spring Boot工程自带logback和slf4j的依赖，所以重点放在编写配置文件上，需要引入什么依赖，日志依赖冲突统统都不需要我们管了。
logback框架会默认加载classpath下命名为logback-spring或logback的配置文件。
将所有日志都存储在一个文件中文件大小也随着应用的运行越来越大并且不好排查问题，正确的做法应该是将error日志和其他日志分开，并且不同级别的日志根据时间段进行记录存储。
1928年，一种通过有限的指令序列来解决这个问题的算法被提出。 冯·诺依曼于1947年开发了“流程图”(Flow Chart)，该流程图是对指令流的可视化表示，目的是通过继承流程图(Flow Process)和多流程图的思想，来规划计算机程序。 但是，这里有一个缺口来指出控制的流程。 因此，“控制流程图”(Control Flow Diagram, CFD)是在20世纪50年代后期发展起来的，用来描述业务流程和程序的控制流。 这不足以查看复杂的系统。 因此，为了通过划分块来揭示整个系统，50年代后期开发了“块状图”。 每个模块的功能以及模块之间的连接将在图中显示。在这个时候，你会发现很多架构师常用的块状图就已经出现了。
了解 Kafka 的内部工作原理有助于理解 Kafka 的行为，也利用快速诊断问题。下面我们来探讨一下这三个问题
我们知道，Kafka 是运行在 ZooKeeper 之上的，因为 ZooKeeper 是以集群形式出现的，所以 Kafka 也可以以集群形式出现。这也就涉及到多个生产者和多个消费者如何协调的问题，这个维护集群间的关系也是由 ZooKeeper 来完成的。如果你看过我之前的文章(真的，关于 Kafka 入门看这一篇就够了)，你应该会知道，Kafka 集群间会有多个 主机(broker)，每个 broker 都会有一个 broker.id，每个 broker.id 都有一个唯一的标识符用来区分，这个标识符可以在配置文件里手动指定，也可以自动生成。
随着互联网的快速发展，企业的IT建设也是飞速发展的，但是在建设企业信息化时没有统筹考虑，建设往往不成体系、重复开发、烟囱式的建设，造成了资源的冗余和浪费，为了针对这些问题逐渐诞生了SOA、ESB、微服务、API网关以及REST等技术，现针对技术点总结如下。
1. API网关剖析
API 网关是一个服务器，也可以说是进入系统的唯一节点。这与面向对象设计模式中的 Facade 模式很像。API 网关封装内部系统的架构，并且提供 API 给各个客户端。它具备授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等功能。
安全控制一直是治理的重要环节，数据脱敏属于安全控制的范畴。对互联网公司、传统行业来说，数据安全一直是极为重视和敏感的话题。数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。涉及客户安全数据或者一些商业性敏感数据，如身份证号、手机号、卡号、客户号等个人信息按照相关部门规定，都需要进行数据脱敏。
在真实业务场景中，相关业务开发团队则往往需要针对公司安全部门需求，自行实行并维护一套加解密系统，而当脱敏场景发生改变时，自行维护的脱敏系统往往又面临着重构或修改风险。此外，对于已经上线的业务，如何在不修改业务逻辑、业务SQL的情况下，透明化、安全低风险地实现无缝进行脱敏改造呢？
Disruptor是一个高性能的异步处理框架，一个轻量级的JMS，和JDK中的BlockingQueue有相似处，但是它的处理速度非常快，获得2011年程序框架创新大奖，号称“一个线程一秒钟可以处理600W个订单”（这有点吓人吧），并且Disruptor不仅仅只有buffer，它提供的功能非常强大，比如它可以帮助我们轻松构建数据流处理（比如一个数据先交给A和B这2个消费者并行处理后再交给C处理，是不是有点想起storm这种流处理，实际上strom的底层就是应用了disruptor来实现worker内部threads的通信）。
本文将使用disruptor最新版3.3.6进行介绍，可以在
https://github.com/LMAX-Exchange/disruptor/releases 下载最新的JAR包开始disruptor之旅吧。
孤立系统的一切自发过程均向着令其状态更无序的方向发展，如果要使系统恢复到原先的有序状态是不可能的，除非外界对它做功。
程序员的职业生涯中难免遇到烂项目，有些项目是你加入时已经烂了，有些是自己从头开始亲手做成了烂项目，有些是从里到外的烂，有些是表面光鲜等你深入进去发现是个“焦油坑”，有些是此时还没烂但是已经出现问题征兆走在了腐烂的路上。
那些不认命的选择与之抗争，但是地上并没有路，当于是人们做出了各自不同的判断和尝试：
线程池（Thread Pool）是一种基于池化思想管理线程的工具，经常出现在多线程服务器中，如Tomcat, MySQL等等。
线程过多会带来额外的开销，其中包括创建销毁线程的开销、调度线程的开销等等，同时也降低了计算机的整体性能。线程池维护多个线程，等待监督管理者分配可并发执行的任务。这种做法，一方面避免了处理任务时创建销毁线程开销的代价，另一方面避免了线程数量膨胀导致的过分调度问题，保证了对内核的充分利用。
这里描述的线程池是JDK 1.8中提供的ThreadPoolExecutor类。
面向数据的架构（Data-Oriented Architecture）由 Rajive Joshi在RTI 的2007 年白皮书中首次提出，而维也纳大学（University of Vienna）的Christian Vorhemus 和Erich Schikuta 在2017 年的 iiWAS 论文中又再次对其进行了描述。 DOA 是对传统二分法的颠覆，它介于单体架构和微服务（Microservices）、面向服务的架构（Service-Oriented Architecture）之间。单体架构由一个单体二进制文件（binary）和数据存储组成；微服务、面向服务的架构由许多小型的、分布式的、独立的二进制文件组成，并且每个二进制文件都有自己的数据存储。在面向数据的架构中，单体数据存储是系统中状态的唯一来源，并由松耦合无状态的微服务对其进行操作。