前言

平常在工作中，经常能听到产品架构、功能架构、系统架构、技术架构等各种关于架构的名词，这就引申出了几个问题，到底是什么架构，架构有什么用，架构都有哪些，我们该如何设计架构等等。本篇文章是从以下三个方面来对架构进行阐述的：

• 架构的定义
• 架构设计的关键要素
• 如何做架构

背景

当前团队内有多个围绕着“特征”建立的系统，有特征系统、用户画像系统、分析门户等。在业务发展初期，这些产品都是紧贴业务的发展而建设的，系统功能模块和沉淀下来的特征也是基于运营活动、业务单元而垂直开发的，给后期带来了巨大的维护和开发成本。

本文的目的在于找到构建自身知识体系的方法，主要是从知识体系的作用、如何看待问题、怎样去划分知识体系以及如何填充知识体系框架来写的。

作用

当需要掌握的知识越来越多时，对个人的挑战也越来越大，如果不把这些知识体系化的组织起来，不仅很容易遗忘一些知识点，个人水平也很难提高。构建知识体系可以帮助我们建立长期的规划和系统性的方法来帮助查缺补漏、确定长期目标，以更好的发展。

进程／线程

1. 查看所有线程数量 ps -eo nlwp,pid,args --sort nlwp
2. 监控 watch -n 1 'ps -eo nlwp,pid,args --sort -nlwp | head'
3. 查看进程线程数量，每个线程的cpu利用率 top -H -p pid

整体架构

在上篇文章中主要是叙述了特征管理系统的顶层设计，从业务的角度对其进行了产品定位，根据它的定位将其划分为元数据管理、特征加工、特征服务三个功能模块，并简要的描述了实时特征计算的大致实现流程。本文再细化特征管理系统的实现。

背景

实时特征对运营活动是必不可少的，特征的质量也会对业务产生直接的影响。但是由于当前没有一个统一的实时特征接入和生产平台，导致特征的产出过程过于混乱，实时特征的质量也是不可控的。当前现象及主要问题有：

简介

窗口机制是Flink流处理的核心，它将无限的流元素分割成有限的窗口。当一个窗口不再增加新元素时，就可以对这个窗口中的所有元素执行计算逻辑。而判断窗口不会再增加新元素的方式有：时间（Watermark）、计数、自定义。其中Watermark代表事件发生时的时间戳或者Flink收到事件时的时间戳。

背景

上游一个服务在调用我们服务的时候突然出现了大量的超时。首先怀疑的是docker机器又挂掉了，然后看了下服务的调用量监控,如下图。

背景

近来在优化一个java项目的性能，在服务架构、gc、代码实现方式都做了基本的优化后，思考如何对其进行更进一步的优化。进一步的优化有两个方向：

1. 使工程本身（架构、gc、代码）再进一步。
2. 验证类似nginx一样的多进程网络服务是否可行。较容易实现，且很容易应用到其它线上服务上。

背景

组内有好几个线上服务，除了业务逻辑不一样，请求处理过程基本上都是一致的。这些服务的执行逻辑都非常简单，但是有几个问题:

1. 单机QPS很低，需要很多台机器
2. 99分位耗时比理论上的长很多
3. 在单机qps达到上限时，服务器的负载却非常低