Kirito 杭州买房记 | 纯小白向杭州购房攻略

2021 年刚开年,解决了人生的一个大事,没错,就像标题里透露的那样,我在杭州买房啦。第一次有在杭州买房这个念头,还要说回 2020 年 6 月,当时和朋友们聚餐时偶然聊到了房子的话题,意外地发现竟然只有自己还没有在杭州买房,其中不乏有 96 年如此年轻的小伙子,自那次聚餐之后,我便开始关注起了杭州的楼市。

先说结果吧,我参与摇号的盘是在杭州市余杭区未来科技城的【天空之城】,摇号结果:

摇号结果

这是个什么概念呢,一共 6181 户参与摇号,房子一共有 1014 套,大概有 1/6 的人算是摇中,而我是摇中的人里面第 2 顺位选房的。记得等待摇号结果的那个周日中午,等待结果通知的那最后一个小时,真的比高考都要紧张,所幸不负期许,人品可以说非常爆炸了,希望摇号这件事没有花光我今年所有运气。

预计在大年初七~初十的时间点还需要办理预审并交付首付,再往后还要办理按揭、网签等流程,还需要忙活一段时间才算尘埃落定。趁着过年这段时间比较空闲,所幸记录一下自己在杭州楼市的经历,这样也给那些刚来到杭州,想要定居于此的小白们一些参考。


谈谈中间件开发

最近频繁地在跟实习生候选人打交道,每次新接触一个候选人,都要花上一定的时间去介绍我们团队,候选人问的最多的一个问题就是「中间件部门一般是干嘛的?」,恰好我之前也接触过一些想从事中间件开发的小伙伴,问过我「现在转行做中间件开发还来得及吗?」诸如此类的问题,索性就写一篇文章,聊聊我个人这些年做中间件开发的感受吧。

什么是中间件开发?

我大四实习时,在一个 20 多人的软件开发团队第一次接触了中间件,当时项目的架构师引入了微博开源的 RPC 框架 Motan,借助于这个框架,我们迅速构建起了一个基于微服务架构的内部电商系统。接着在项目中,由于业务需求,我们又引入了 ActiveMQ…在这个阶段,我已经在使用中间件了,但似乎没有接触到中间件开发,更多的是使用层面上的接触。

我毕业后的第一份工作,公司有几百号研发,当时的 leader 看我对中间件比较感兴趣,有意把我分配在了基础架构团队,我第一次真正意义上成为了一名”中间件研发“,平时主要的工作,是基于开源的 Kong 和 Dubbo,进行一些内部的改造,以提供给业务团队更好地使用。这个阶段,做的事还是比较杂的,业务团队对某些中间件有定制化的需求,都需要去了解这个中间件,熟悉源码。这段时间,也是我成长最快的一个时期,我是在这个期间学会了 Docker、Neo4j、Kong 等以前从来没接触过的技术,并且更加深入地了解 Dubbo 这类 RPC 框架的原理。可能坐在我旁边的就是一个订单部门的同学,抛了一个功能点让我来改造。

现在,我供职于阿里云云原生中间件,相较于上一份中间件研发工作,阿里云这类互联网大公司,任意一个中间件都有少则数人,多则数十人负责,中间件部门和业务部门之间也有着明确的界限。在这里,中间件团队的职责可以细分为三个方向:

  1. 中间件团队会被业务团队的需求所驱动,为集团内部提供定制化的解决方案,俗称「自研」。所以你可能并不了解到 HSF、Diamond 这些阿里内部的中间件。
  2. 中间件团队会从事开源,花费大量的精力提升中间件的极致性能,提升开源影响力,引领技术先进性。这部分中间件则比较为人所熟知,例如 Dubbo、Spring Cloud Alibaba、RocketMQ、Nacos。
  3. 中间件会在阿里云输出商业化产品,相比开源产品,提供更高的 SLA、更强大的功能、更友好的交互。这部分商业化产品诸如:微服务引擎 MSE、消息队列 RocketMQ、分布式应用链路追踪 ARMS。

我的这三段经历,正好反应了不同规模的公司对中间件开发的不同需求。小公司使用中间件,例如 RPC、MQ、缓存等,基本是由业务开发人员自己维护的。但如果后台研发达到数百人,基本就会组建自己的中间件团队,或者选择使用阿里云等云厂商提供的中间件产品。


从校园到职场,聊聊实习这点事

从我最近发的实习招聘文章就可以知道,我最近在忙春招的事了,本人也非常“荣幸”,担任了我们团队这次春招的负责人。陆陆续续沟通了很多学生,于是在这个周末抽出了一点时间,跟大家聊聊我对校园实习的一些看法。


ACK 部署 Apache apisix-ingress-cotroller

背景

Ingress 是 Kubernetes 中一个值得关注的模块,作为外部访问 Kubernetes 集群服务的入口,市面上已经有了多种 Ingress controller 的实现。国产实时、高性能的 API 网关 Apache APISIX 推出的 Apache/apisix-ingress-controller 就是其中一员,作为功能更加强大的 ingress 对外提供服务。笔者准备在阿里云 ACK 集群上部署测试。


用了这么久配置中心,还不知道长轮询是什么?

前言

传统的静态配置方式想要修改某个配置时,必须重新启动一次应用,如果是数据库连接串的变更,那可能还容易接受一些,但如果变更的是一些运行时实时感知的配置,如某个功能项的开关,重启应用就显得有点大动干戈了。配置中心正是为了解决此类问题应运而生的,特别是在微服务架构体系中,更倾向于使用配置中心来统一管理配置。

配置中心最核心的能力就是配置的动态推送,常见的配置中心如 Nacos、Apollo 等都实现了这样的能力。在早期接触配置中心时,我就很好奇,配置中心是如何做到服务端感知配置变化实时推送给客户端的,在没有研究过配置中心的实现原理之前,我一度认为配置中心是通过长连接来做到配置推送的。事实上,目前比较流行的两款配置中心:Nacos 和 Apollo 恰恰都没有使用长连接,而是使用的长轮询。本文便是介绍一下长轮询这种听起来好像已经是上个世纪的技术,老戏新唱,看看能不能品出别样的韵味。文中会有代码示例,呈现一个简易的配置监听流程。


Dubbo 基础教程:使用 Nacos 实现服务注册与发现

什么是 Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

在接下里的教程中,将使用 Nacos 作为微服务架构中的注册中心,替代 ZooKeeper 传统方案。


Service 层需要实现接口吗

前几天看技术交流群的话题,又刷到了「Service 层和 Dao 层真的有必要每个类都加上接口吗?」这个问题,之前简单回答了一波,给出的观点是「看情况」

现在结合我参与的项目以及阅读的一些项目源码来看,如果项目中使用了像 Spring 这样的依赖注入框架,那可以不用接口

先来说说为什么使用了依赖注入框架以后,可以不使用接口。


Spring Cloud 终于改了,为什么要用日期来做版本号?

Spring Cloud 终于改了

最近 Spring Cloud 把版本号从 A 到 Z 的伦敦地铁站,改成用日期命名了。

也就是从 Greenwich.SR6, Hoxton.SR9 这样的风格改成了 2020.0.0 的形式。广大人民终于不用为 Spring Cloud 的版本号烦恼了。

Spring Cloud 推广不力,固然有自身复杂的原因,版本号太复杂也是一个坑。

以日期为版本号,即所谓的 Calendar Versioning,可以参考这个网站:


Nacos 集群部署模式最佳实践

1 前言

Nacos 支持两种部署模式:单机模式和集群模式。在实践中,我们往往习惯用单机模式快速构建一个 Nacos 开发/测试环境,而在生产中,出于高可用的考虑,一定需要使用 Nacos 集群部署模式。我的上一篇文章《一文详解 Nacos 高可用特性》提到了 Nacos 为高可用做了非常多的特性支持,而这些高可用特性大多数都依赖于集群部署模式。这篇模式文章便是给大家介绍一下,在实践中可以被采用的几种集群部署模式,无论你是希望自行搭建 Nacos,还是希望对 MSE 商业版 Nacos 有一个更加深刻的理解,我都很乐意跟你分享下面的内容。

由于篇幅限制,本文不会介绍如何将一个多节点的 Nacos 集群启动起来,主要介绍的是一个多节点的 Nacos 集群启动之后,我们的应用如何很好地连接到 Nacos 集群,即客户端视角。这中间我们会引入一些其他组件以解决一些问题,本文标题也可以叫做《Nacos 接入点最佳实践》。我将会介绍以下三种方案:直连模式、 VIP 模式和地址服务器模式,并对它们进行对比。


一文详解 Nacos 高可用特性

前言

服务注册发现是一个经久不衰的话题,Dubbo 早期开源时默认的注册中心 Zookeeper 最早进入人们的视线,并且在很长一段时间里,人们将注册中心和 Zookeeper 划上了等号,可能 Zookeeper 的设计者都没有想到这款产品对微服务领域造成了如此深厚的影响,直到 SpringCloud 开始流行,其自带的 Eureka 进入了人们的视野,人们这才意识到原来注册中心还可以有其他的选择。再到后来,热衷于开源的阿里把目光也聚焦在了注册中心这个领域,Nacos 横空出世。

注册中心

Kirito 在做注册中心选型时的思考:曾经我没得选,现在我只想选择一个好的注册中心,它最好是开源的,这样开放透明,有自我的掌控力;不仅要开源,它还要有活跃的社区,以确保特性演进能够满足日益增长的业务需求,出现问题也能及时修复;最好…它的功能还要很强大,除了满足注册服务、推送服务外,还要有完善的微服务体系中所需的功能;最重要的,它还要稳定,最好有大厂的实际使用场景背书,证明这是一个经得起实战考验的产品;当然,云原生特性,安全特性也是很重要的…

似乎 Kirito 对注册中心的要求实在是太高了,但这些五花八门的注册中心呈现在用户眼前,总是免不了一番比较。正如上面所言,功能特性、成熟度、可用性、用户体验度、云原生特性、安全都是可以拉出来做比较的话题。今天这篇文章重点介绍的是 Nacos 在可用性上体现,希望借助于这篇文章,能够让你对 Nacos 有一个更加深刻的认识。


Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×