IDEA 插件推荐:Cloud Toolkit 测评

产品介绍

Cloud Toolkit 是一款 IDE 插件,帮助开发者更高效地开发、测试、诊断并部署应用。开发者能够方便地将本地应用一键部署到任意机器,或 ECS、EDAS、Kubernetes;并内置 Arthas 诊断、高效执行终端命令和 SQL 等。

对这款产品最直观的感受:这是一款发布工具,帮助用户在 IDE 中直接打包应用并部署到各种终端。原本看到其产品介绍位于阿里云的页面中,以为是一款和阿里云服务强绑定的产品,但试用过后发现,即使对于普通的云主机,其也非常适用,可以解决很多开发运维的痛点,非阿里云用户可以放心使用。


Dubbo 的前世今生 & Dubbo Meetup 南京

Dubbo 的前世今生

2011 年 10 月 27 日,阿里巴巴开源了自己的 SOA 服务化治理方案的核心框架 Dubbo,服务治理和 SOA 的设计理念开始逐渐在国内软件行业中落地,并被广泛应用。自开源后,许多非阿里系公司选择使用 Dubbo,其中既有当当网、网易考拉等互联网公司,也有中国人寿、青岛海尔等传统企业。


提问前,请先让自己成为值得被教的人

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

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


如何向开源项目做贡献 (以 incubator-dubbo 为例)

Github 上有众多优秀的开源项目,大多数 IT 从业者将其当做了予取予求的工具库,遇到什么需求,先去 Github 搜一把,但有没有想过有一天自己也可以给开源事业做一些贡献呢?本文将会以 incubator-dubbo 项目为例,向你阐释,给开源项目做贡献并不是一件难事。


技术精进的三境界

最近更新了一篇 Docker 的文章,朋友跟我反馈说效果并不是很好,我回头看了下,的确没有我自己的特色,没有太多思考,让公众号显得有些「百货」了。经过反思,今后只在个人博客更新 Docker 相关的个人学习经验(传送门),个人公众号还是主要推送和 Java 结合较为紧密的内容。


离开魔都后的一点感想

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

技术沙龙

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

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

南京 IAS 架构师峰会观后感

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Your browser is out-of-date!

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

×