持续Java学习中

通俗地说，所谓的IM就是聊天。实时投递单聊消息和群聊消息消息撤回消息回执消息勿扰准确性消息不可丢失实时性有序性消息：用户发出的任何内容用户状态：在线、离线、挂起设备/终端：用户使用IM的客户端，通常包括移动端和Web端单聊：两个用户一对一聊天的模式群聊：多个用户聊天的模式绘画：描述用户通过聊天建立的关联关系。

增加社交互动促进用户的参与和分享促进用户生成内容增加社交产品的流量发布评论删除评论拉取内容评论列表拉取用户评论列表运营评论评论模式：单级评论模式二级评论模式盖楼评论模式。

Feed 流的功能在当今的互联网应用和网络社交平台中非常重要，它是一种以时间线为基础的信息流展示形式，把用户感兴趣的内容呈现在用户的Feed页面上。如果你使用过一些互联网应用就会发现，很多互联网应用的主页都是Feed页面，它们把Feed流当作自己的“门面”。Feed 流在内容聚合维度上包括但不限于如下几种形式。

任何注重用户互动的互联网应用，都会将用户之间的关注功能作为产品的重要功能之一，因此它允许用户订阅其他用户的动态，以便获取用户的更新和动态。促进社交互动个性化推荐增加用户粘性。

排行榜场景：游戏排行榜、商品排行榜、视频排行榜、社交排行榜排行榜特点：曝光量大、竞争激烈、实时变化、周期滚动使用关系型数据库存储会遇到性能瓶颈、磁盘IO问题，所以排行榜的实现不太适合关系型数据库。可以使用Redis的ZSET数据结构。ZSET是一种有序集合形式，该集合由Member组成，每个Member都有一个Score（积分），集合会按照Score自动排序。所以，目前Redis的ZSET便成为实现排行榜的首选。

1）用户发布的每个作品，有点费数、分享数、评论数、转发数、收藏数;2）用户主页，有关注数、粉丝数、作品数、热度等;3）评论列表中的每条评论，有点费数、点踩数。

内容发布系统旨在管理从用户发布内容到内容为大众所见的全生命周期流程，包括新建内容、修改内容、内容审校、内容分发、内容下架等。可以说，内容发布系统是面向用户的应用的核心功能性系统之一。内容发布系统并不是一个简单地进行内容创建与数据存储的系统，其中有很多的业务细节与技术细节需要考虑。这里先抛出如下几个实际问题：1. 内容的表现形式可能足短文字、长文字、图片、音频、视频，也可能是这些表现形式的组合，我们应该怎样合理地存储内容？2. 用户发布的内容可能涉及反动、血腥、色情等问题，我们应该怎样迅速检测并屏蔽这些

在HTML5下定义了一种全新的通信协议：WebSokcet，它是一种基于TCP的全双工通信协议，允许在客户端与服务端之间建立全双工通信连接，这样客户端和服务端都可以主动将数据推送到另一端由于WebSocket协议很适合消息推送的场景，所以我们可以在客户端开发一个基于WebSocket协议的长连接通信SDK，客户端通过调用这个SDK来串门用于接收服务器推送消息的通道

OAuth2标准：开放的授权标准，允许用户授权乙方应用访问他们存储在第三方平台的信息，而不需要将第三方平台的用户名和密码提供给乙方应用。用户在登录完成后，服务端会基于用户身份信息加密生成一个安全的令牌返回给客户端，客户端的后续请求在请求头中携带此令牌给服务端，服务端通过验证令牌的合法性来验证用户是否已经登录。当用户输入密码登陆时，先对输入密码进行加密，然后将加密的密码与数据库中存储的值进行比较，如果一致则认为密码正确。成功则解析用户，并回写长令牌用户信息，不成功则表示登录过气，需要重新登录。

根域名服务器是全球互联网的中枢神经，它负责互联网顶级域名的解析，即它学握着全部顶级城名的名称与IP地址的映射关系。每个域名对应的权威域名服务器都可能不同，每个权威域名服务器仅可解析它负责的域名，比如负责google.com 域名的权威域名服务器无法解析城名apple.com。Nginx 是一种自由的、开源的、高性能的 HTTP 服务器和反向代理服务器，同时也是IMAP、POP3、SMTP 的代理服务器。权威域名服务器负责对特定的域名进行解析，它管理顶级域名下的二级域名、三级域名、四级城名等的服务器。

由于网络原因或服务设计问题，微服务一般很难保证100%对外可用。如A->B->C->D，D因为请求量突增或设计不合理导致宕机，导致C服务请求大量阻塞，最终拖垮B和A。幂等性 = 请求接口携带唯一ID + 下游接口具备幂等校验策略。内容总结自《亿级流量系统架构设计与实战》接口必备幂等特性（读接口天然具备幂等）熔断器（在业务上游）三种状态。

高性能（PCT99）：响应时间PCTn统计方式，表示请求响应时间按从小到大排序后，第n分位的响应时间。即如果100个请求，从小打大排序后，第99分位的响应时间是100ms，则PCT99=100ms。从经验数据来看，平均响应时间200ms，且PCT99=1s的高并发系统基本能够保证高性能的要求；如果请求的响应时间在200ms以内，用户不会感受到延迟；如果请求响应的时间超过1s，用户会明显感受到延迟高可用性（服务几个9）

本文以我参与的某公司xx项目为例，论述了xx（论文题目要求）。该项目的目标是xx（产品能力），实现xx（主要功能），包括xx（辅助功能）。在此项目中，我作为系统分析师及主要管理人员，主导了该项目的系统分 析和设计等工作。在项目系统的xx（点题），采用xx（题目技术点说明），实现了xx（技术点带来的价值），保证了业主方对于项目各项功能和质量指标的实现，项目最终取得了成功。

内容来自《系统架构设计师教程》，筛选系统架构设计师考试中分值重点分布的章节，根据章节的内容整理出相关思维导图。

在迁移到微服务架构之前，确保你的软件交付问题是由于业务需求超出单体架构承载能力而导致的。在架构重构之前，你可以通过改进软件开发过程来加速交付。通过逐步开发一个绞杀者应用程序来迁移到微服务非常重要。绞杀者应用程序是一个新的应用程序，由围绕现有单体应用构建的微服务组成。你应该尽早并经常证明自己的价值,以确保业务团队支持迁移工作。将微服务引入架构的一个好方法是将新功能作为服务实现。这样做可以使你使用现代技术和开发过程快速轻松地开发功能。这是快速展示迁移到微服务价值的好方法。

要在计算机上部署Restaurant Service，首先要安装必要的运行时环境，在本例中为JDK。如果它是WAR文件，则还需要安装Web容器，例如Apache Tomcat。配置完计算机后，将程序发布包复制到计算机并启动该服务。每个服务实例都作为JVM进程运行。理想情况下，你已经设置好部署流水线，它会自动将服务部署到生产环境。部署流水线构建可执行的JAR文件或WAR文件。然后，它调用生产环境的服务管理接口来部署新版本。

身份验证：验证尝试访问应用程序的应用程序或人员(安全的术语叫主体)的身份。例如,应用程序通常会验证访问主体的凭据，例如用户的ID和密码，或应用程序的API密钥。访问授权：验证是否允许访问主体对指定数据完成请求的操作。应用程序通常使用基于角色的安全性和访问控制列表(ACL)的组合。基于角色的安全性为每个用户分配一个或多个角色，授予他们调用特定操作的权限。ACL授予用户或角色对特定业务对象或聚合执行操作的权限。审计：跟踪用户在应用中执行的所有操作，以便检测安全问题，帮助客户实现并强制执行合规性。

其实就是抽一层，将前端的组合逻辑抽到统一的一层，这一层就是API Gateway层API Gateway负责请求路由、API组合和协议转换。来自外部客户端的所有API请求首先转到APl Gateway，后者将一些请求路由到相应的服务。API Gateway使用API组合模式处理其他请求，调用多个服务并聚合结果。它还可以在客户端友好的协议(如HTTP和WebSockets)与客户端不友好的协议之间进行转换。API组合：API Gateway通常不仅仅是简单地扮演反向代理的角色。

这是最简单的方法，应尽可能使用。它的工作原理是让拥有数据的服务的客户端负责调用服务，并组合服务返回的查询结果，实现从多个服务检索数据的查询。它将持久化数据模型和使用数据的模块分为两部分：命令端和查询端。命令端模块和数据模型实现创建、更新和删除操作（缩写为CUD，例如:HTTP POST、PUT和DELETE）。查询端模块和数据模型实现查询（例如HTTP GET）。查询端通过订阅命令端发布的事件，使其数据模型与命令端数据模型保持同步。实现从多个服务检索数据的查询具有挑战性，因为每个服务的数据都是私有的。

某些系统操作需要更新分散在多个服务中的数据。传统的基于XA/2PC的分布式事务不适合现代应用。更好的方法是使用Saga模式。Saga是使用消息机制协调的一组本地事务序列。每个本地事务都在单个服务中更新数据。由于每个本地事务都会提交更改，因此如果由于违反业务规则而导致Saga必须回滚，则必须执行补偿事务以显式撤销更改。可以使用协同或编排来协调Saga的步骤。在基于协同的Saga 中，本地事务发布触发其他参与方执行本地事务的事件**。

在领域驱动设计的上下文中，领域事件是聚合发生的事情。它由领域模型中的一个类表示。事件通常代表状态的变化。即，聚合在被创建时，或发生其他重大更改时发布领域事件。在命名领域事件时，我们往往选择动词的过去分词。这样的命名能够明确表达事件的一些属性。领域事件的每个属性都是原始值或值对象。例如，Ordercreated事件类具有orderId属性。即事件包含的数据是事件的简化内容，如id。还是接受方需要的事件内容信息虽然事件增强简化了接收方，但缺点是它可能会使领域事件的稳定性降低。

事件溯源是一种以事件为中心的技术，用于实现业务逻辑和聚合的持久化。聚合作为一系列事件存储在数据库中。每个事件代表聚合的状态变化。聚合的业务逻辑围绕生成和使用这些事件的要求而构建。1、事件溯源通过事件来持久化聚合将聚合的字段映射到数据库表的列，将聚合的实例映射到数据库表的行。事件溯源采用基于领域事件的概念来实现聚合的持久化，这是一种非同寻常的方法。它将每个聚合持久化为数据库中的一系列事件，我们称之为事件存储。2、事件代表状态的改变使用事件溯源时，事件不再是可有可无的。

有很多进程间通信技术可供开发者选择。服务可以使用基于同步请求／响应的通信机制，例如HTTP REST或gRPC。另外，也可以使用异步的基于消息的通信机制，比如AMQP或STOMP。消息的格式也不尽相同。服务可以使用具备可读性的格式，比如基于文本的JSON或XML。也可以使用更加高效的、基于二进制的Avro或Protocol Buffers 格式。客户端和服务端的交互方式可以分为两个不同的维度维度一：一对一、一对多维度二：同步模式、异步模式一对一一对多同步模式请求/响应无异步模式。

我们需要拿到领域专家或者现有应用的需求文档。跟所有的软件开发一样，定义架构也是一项艺术而非技术。定义应用程序架构的三步式流程。但我们也需要名单，世界上没有一个机械化的流程可以遵循，然后指望这个流程输出一个合理的架构。我们只能介绍一个大概的方法，现实世界中，这是一个不断迭代和持续创新的过程。应用程序是用来处理客户端请求的，因此定义其架构的第一步是将应用程序的需求提炼为各种关键请求。但是，不是根据特定的进程间通信技术(如REST或消息)来描述这些请求，而是使用更抽象的系统操作这个概念。

microservice用来指代微服务这类架构设计风格，而构成微服务架构的是每一个具体的实例，是service（服务）。所以我们应该说，“这个系统采用了微服务架构设计，由若干个服务构成”。这里借助了Martin Abbott和Michael Fisher的名著《The Art of Scalability》 的启发，该书中描述了一个三维可扩展模型：“扩展立方体”，这个模型描述了一个应用程序的三个维度X轴扩展：在多个实例之间实现请求的负载均衡。

我们总说书上写的是死的，但人是活的，不要死读书。但在我看来，灵活使用的前提是你的知识储备已经具备了灵活掌握的程度，断然不是遇到别人引用书中的话语，并且这是一个我们没见过，且与我们认知有些违背，我们就说别人是死读书。这句话像极了对别人掌握知识的蔑视，我们都应该清楚的认识到，事物发展都需要过程。这一切的一切得结合时代、结合双方的认知程度等众多因素才能做出结论，不过当下我认为最好的状态，还是只对过程进行阐述，不下结论，《代码整洁之道》书中的观点亦是如此。

我们总是说自己的项目历史代码太多，是个屎山。自己也深度思考过这个问题，什么样的代码才能定义为屎山（不能怪业务太复杂吧）？到底是自己理解能力不行还是确实代码写的烂（肯定不愿意都是自己的问题）？或者说自己写的代码其实也是屎山，不理解只是因为一坨屎不认识另一坨屎罢了，这很正常（亲生经历过这种场景）。“我本可以忍受黑暗，如果我未曾见过光明”，看到好代码，内心是愉悦的（特别是写好代码的人天天和自己一起吃饭，只能感慨——牛哇牛哇）说不出具体好的逻辑，但内心就觉得这个是好东西（应该是编码的细节）。

由于最近上班工作量不饱和，于是我简单的划完了JAVA 8实战这本书，特在此对内容进行一个归纳总结。文章目录一、书籍大纲二、内容总结1、Lambda行为参数化内部类优化设计模式2、Stream流流的概念简单API操作其他3、接口默认方法4、Optional5、CompletableFuture异步任务6、LocalDate新日期API7、函数式编程8、其他 一、书籍大纲以下是书中所有章节的一个概括： 二、内容总结如果你问我Java 8 这本书讲了什么，我必然不会给你罗列上面的章节清.