前言

继上一篇文章《Kirito 杭州买房记 | 纯小白向杭州购房攻略》过去已经有 2 年了，预计在今年 6~9 月，我的房子就要交付了，所以我也开始了全屋定制之路。现在杭州的期房大多数是精装修交付，也就是说厨房和卫生间等部分都包含在房价中，我需要操心的全屋定制部分仅包含：

柜子部分

• 卧室衣柜
• 书房书柜
• 餐边柜
• 电视柜

家具部分

• 沙发
• 茶几
• 餐桌

最近一两个月，我跑遍了附近各个全屋定制的商家，从一个装修小白，成长为了一个略懂的小白，本文记录了我这段时间的积累，可以当做一份入门攻略。

本文主要介绍打柜子的部分，家具部分捎带提一下。

本文偏小白向，如果描述有偏差，欢迎指正，适合阅读人群：从未经历过但即将需要全屋定制，未亲自参与过全屋定制，关注了 Kirito 并好奇怎么发了一个技术无关的文章的读者。

背景

最近由于业务需求，我负责的一块系统需要对外开放 Open API，原本不是什么难事，因为阿里云内部的 Open API 开放机制已经非常成熟了，根本不需要我去设计，但这次的需求主要是因为一些原因，需要自己设计一些规范，那就意味着，需要对 Open API 进行一些规范约束了，遂有此文。

Open API 和前端页面一样，一直都是产品的门面， Open API 不规范，会拉低产品的专业性。在云场景下，很多用户会选择自建门户，对接云产品的 Open API，这对我们提出的诉求便是构建一套成熟的 Open API 机制。

站在业务角度，有一些指导原则，指导我们完善 Open API 机制：

• 前端页面使用的接口和 Open API 提供的接口是同一套接口
• 任意的前端页面接口都应该有对应的 Open API

站在技术角度，有很多的 API 开放标准可供我们参考，一些开源产品的 Open API 文档也都非常完善。一方面，我会取其精华，另一方面，要考虑自身产品输出形态的特殊性。本文将围绕诸多因素，尝试探讨出一份合适的 Open API 开放规范。

前言

陪伴了我 3 年的 Mac 在几个月前迎来了它的退休时刻，我将其置换成了公司新发的 Mac M1。对电子产品并不太感冒的我，并没有意识到 M1 是 ARM 架构的（除了个别软件的安装异常之外），显然，Mac M1 做的是不错的，我并没有太多吐槽它的机会。这也是我第一次近距离接触 ARM 架构的机会。

很快，在工作上，我遇到了第二次跟 ARM 打交道的机会。我们越来越多的客户，开始选择 ARM 架构的服务器作为 IaaS 层资源，这给我们的交付带来了一些工作量。适配工作中比较重要的一环便是 Docker 镜像，需要产出支持 ARM 架构的版本。

本文主要记录笔者在构建多系统架构支持的 Docker 镜像时的一些经验，以及一些个人的理解。

每一个不恰当的提问都在消耗别人对你的耐心，程序员届早已经有了诸如《提问的智慧》之类的经典文章介绍了什么是蠢问题，如何避免问蠢问题。然而，常年混迹于十几个技术交流微信群的我，发现很多小白程序员并不懂得这一点，为改善微信群的技术交流氛围，转此文，意图是让大家在担任提问者的角色时，尽可能提高提问的素质，让自己成为值得被教的人。

原文出处：https://github.com/aptx4869yuyang2017/How-To-Ask-Questions-The-Smart-Way

还记得上一篇记录我心情的随笔是写在离开魔都，去往南京的时候，此时的我，又来到了杭州。工作发生了变故，心境也发生了变化，倒是有不少东西想跟各位来聊一聊，择其三汇成此文。

看过我公众号简介的朋友会发现，我公众号的定位是分享一些个人的技术博客和杂谈，这其中的杂谈不仅包括了技术杂谈，也包含了自己的一些感悟。所以借此澄清，这是一篇杂文！总结了我在魔都这一年半不同角度的感悟。

技术沙龙

我前几天刚发过一个朋友圈：魔都得天独厚的优势便是各种技术沙龙，其中不乏有很多是免费的。我在魔都这些日子，参加了大概 13-15 场技术沙龙。参加这种技术分享会的动机很单纯，大家都是去学习互联网最前沿的技术的，但隐性的好处也很多：

1. 你可以认识很多跟你同样有积极性的同行们，试想一下，这样一批放弃了周末休息时间，不睡懒觉，不打游戏，不陪妹子的人，必然是对技术充满了热情的一帮人。我有不少微信好友是在技术分享会上添加的。
2. 有些朋友身处传统行业，平时的业务接触不到高并发，JVM 这些看似高大上的名词，但是技术沙龙带来了这样的可能性，让你没吃过猪肉，至少见过猪跑。映像比较深刻的是“美团点评技术团队”定期举办的技术沙龙，参加了两次，分享的很棒，而且大多数情况下，只需要在 APP 中报名即可参加。
3. 同行间的技术方案分享。很有可能你正在负责公司某块业务的技术选型，而沙龙正好涉及了相关的内容，可以静静聆听下别人的解决方案，通过别人落地的架构，来指导自己的选型。这一点我也有例子真实的例子与之对应，大概是 17 年初，有一场 daocloud 举办的 springcloud 社区沙龙，由 DD 带来的 zuul 源码解读以及案例分享，记忆尤为深刻，当时我所在的公司也恰巧在对 zuul 进行改造，而 DD 分享的主题对于我的工作非常有帮助。

上周六，周日在南京举办了 IAS 架构师峰会，这么多人的技术分享会还是头一次参加，大佬云集，涨了不少姿势。特此一篇记录下印象深刻的几场分享。由于全凭记忆叙述，故只能以流水账的形式还原出现场的收获。

大型支付交易平台的演进过程

陈斌，《架构即未来》译者，易宝支付 CTO。

交易系统具备以下特点，交易量大，并发度高，业务敏感度高，响应速度容忍度低… 从而使得支付交易平台需要有以下的特点：

• 高可用：7X24*365 随时可用
• 高安全：需满足 PCI-DSS 要求
• 高效率：每笔交易的成本要低
• 高扩展：随业务的快速发展扩张

从以上几点话题引申出了系统扩展的三个阶段

**X 轴扩展 – 扩展机器 **

也就是通俗意义中集群方案，横向扩展，通过添加多台机器负载均衡，从而扩展计算能力，这是最简单粗暴，也是最直接易用的方案。

**Y 轴扩展 – 拆分服务 **

当水平扩展遇到瓶颈后，可以进行服务的拆分，将系统按照业务模块进行拆分，从而可以选择性定制化地扩展特定的模块。如电商系统中拆分出订单模块，商品模块，会员模块，地址模块… 由于各个模块的职责不同，如订单模块在双 11 时压力很大，可以多部署一些订单模块，而其他压力不大的模块，则进行少量地部署。

**Z 轴扩展 – 拆分数据 **

服务拆分之后仍然无法解决与日俱增的数据量问题，于是引发了第三层扩展，数据的分片，我理解的 sharding，不仅仅存在于数据库，还包含了 redis，文件等。

另外陈斌老师还聊了一个有意思的话题，系统可用性下降的原因根源是什么？最终他给出的答案是：人。系统升级后引发的事故 80% 是由于人的误操作或者触发了 bug 等人为因素导致的，是人就会手抖。借此引出了单元测试，持续集成，持续交付的重要性。健全这三者是保障系统可用性的最大利器。

在技术晚宴，陈斌老师又分享了一些管理经验：** 如何打造一支优秀的技术团队 **。

分析了构成团队的四要素：

• 人员：健全职级体系，区别考评，挖掘潜能，及时鼓励，扁平化管理
• 组织：面向产出，利于创新，敏捷小团队
• 过程：聚集问题的根源，适当地使⽤用 ITIL，不断优化过程，自动化取代人工
• 文化：鼓励分享，打破 devops 的边界，鼓励创新，树⽴立正确的技术负债观

对于技术人员来说可能有点抽象，不过对于立志于要成为 CIO 的人肯定是大有裨益的，具体的理解可以参考《架构即未来》中的具体阐释。(ps：这里的架构并不是指技术架构，别问我为什么知道，问问我看了一半后在落灰的那本书，你什么都明白了)

就在最近，项目组开始强调开发规范了，今天分享一个变量名命名不规范的小案例，强调一下规范的重要性。例子虽小，但却比较有启发意义。

Boolean 变量名命名规范

16 年底，阿里公开了《Java 开发规范手册》，其中有一条便是“布尔类型不能以 is 为前缀”。规范中没有举出例子，但是给出了原因：会导致部分序列化框架的无法解析。

看看错误的示范，会导致什么问题，以 Spring 中的 jdbcTemplate 来进行实验。

从去年实习到今年转正，陆陆续续接触了大概四个项目。有电商类，互联网保险类，也经历过管理系统。幸运的是，这些项目都是从零开始，避免了让我去维护不堪入目的老旧系统。而这么多项目中令我印象最深刻的，就要属上一个电商项目了。这也是我接触到的真正意义的第一个微服务项目，到今天回首去看曾经的这个项目，有很多突破性地尝试，同时不可避免地也踩入了一些坑点，毕竟摸着石头过河。今天想聊聊我对上一个电商项目的反思。

项目简介

准确的说是一个第三方的电商项目，商品来源是由主流电商的 http 接口提供（目前接入了京东，苏宁），打造我们自己的商城体系。使用的技术包括 springboot，jpa，rpc 框架使用的是 motan，数据库使用的是 oracle，基本都还算是主流的技术。

前言

回首大三下的暑假，那时候刚开始出来找实习，如今已经即将进入大四下学期，恍惚间，已经过去了 8，9 个月。写这篇文章的初衷就是想结合自己的经验给即将要出来找工作的应届生一些建议，想当初自己刚出来时，也得到过热心学长的教导，权当一种传递吧。