Mobabel

Just One Pure ITer

Mobabel Blog

0

Collection

[转]从业近20年，我对于软件架构这件事的一些思考

本文要点预览：因为软件系统的分布式特点以及开发团队的分布性，了解软件架构的基础变得越来越重要。而在过度设计和毫无设计之间，我们应该把注意力放在对软件系统有重大影响的决策和权衡上。好的架构师应该是团队的活跃分子，不仅能够进行代码协作，还能为团队提供技术指导。软件架构中的沟通环节极具挑战性。C4 模型对软件架构中的沟通环节进行了结构化，从一个上下文图表开始，再逐步深入到系统的各个技术层面。实际上，可以多花一些时间实现好的架构，好的架构能够带来敏捷。

0

RPC Solutions

[转]一个针对所有RPC框架的性能测试

几乎所有的 RPC 框架都宣称自己是“高性能”的，那么实际结果到底如何呢, 让我们来做一个性能测试吧。 项目地址: https://github.com/hank-whu/rpc-benchmark 测试说明 仅限于 Java； 客户端使用 JMH 进行压测, 32 线程, 10 次预热, 3 次运行； 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统； 所有类库版本在发布时都是最新的, 除非存在 bug； 所有框架都尽量参考该项目自带的 Benchmark 实现； 将会一直持续, 不定期发布测试结果； 测试用例 boolean existUser(String email),...

0

iOS

[转]APP 网络优化概述

一般开发一个 APP，会直接调用系统提供的网络请求接口去服务端请求数据，再针对返回的数据进行一些处理，或者使用AFNetworking/OKHttp这样的网络库，管理好请求线程和队列，再自动做一些数据解析，就结束了。 但对于一些大型 APP，还会想针对网络的一些问题进行进一步优化，包括： 速度：网络请求的速度怎样能进一步提升？ 弱网：移动端网络环境随时变化，经常出现网络连接很不稳定可用性差的情况，怎样在这种情况下最大限度最快地成功请求？ 安全：怎样防止被第三方窃听/篡改或冒充，防止运营商劫持，同时又不影响性能？

0

MS Design Princinple

[转]微服务架构技术栈选型手册

1. 一、前言 2014 年可以认为是微服务 1.0 的元年，当年有几个标志性事件，一是 Martin Fowler 在其博客上发表了”Microservices”一文，正式提出微服务架构风格；二是 Netflix 微服务架构经过多年大规模生产验证，最终抽象落地形成一整套开源的微服务基础组件，统称 NetflixOSS，Netflix 的成功经验开始被业界认可并推崇；三是 Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系，推出 Spring Cloud 微服务开发技术栈。 一晃三年过去，微服务技术生态又发生了巨大变化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless 等新技术新理念你方唱罢我登场，不知不觉我们又来到了微服务 2.0 时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累，我想总结并提出一些构建微服务 2.0 技术栈的选型思路，供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块，我也会给出一些定制自研的设计思路。 2. 二、选型准则 对于技术选型，我个人有很多标准，其中下面三项是最重要的： 2-1....

0

MS API Gateway

[转]API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd

1. 前几天拜读了 OpsGenie 公司（一家致力于 Dev & Ops 的公司）的资深工程师 Turgay Çelik 博士写的一篇文章（链接在文末），文中介绍了他们最初也是采用 Nginx 作为单体应用的网关，后来接触到微服务架构后开始逐渐采用了其他组件。 我对于所做的工作或者感兴趣的技术，喜欢刨根问底，所以当读一篇文章时发现没有看到我想要看到的设计思想，我就会四处搜集资料，此外这篇文章涉及了我正在捣鼓的 Spring Cloud，所以我就决定写一篇文章，争取能从设计思路上解释为什么会有这样的性能差异。

0

MS Design Princinple

[转]运维能力是微服务架构的先决条件

  今天我们来聊聊微服务架构模式下的一个核心概念：应用。 我会从这几个方面来讲：应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望，在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要从应用的角度来分析和看待问题。

0

Monolith to Distributed

[转]聊聊分布式系统架构

  1. 写在前面 最近几年，我们一直在谈论各式各样的架构，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等。还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等。面对这么多纷乱的技术，我看到很多团队或是公司都是一个一个地去做这些技术，非常辛苦，也非常累。这样的做法就像我们在撑开一张网里面一个一个的网眼。 其实，只要我们能够找到这张网的“纲”，我们就能比较方便和自如地打开整张网了。那么，这张“分布式大网”的总线——“纲”在哪里呢？我希望通过这一系列文章可以让你找到这个“纲”，从而能让你更好更有效率地做好架构和工程。

0

SOA Architect to MS Architect

[转]5年时间服务器从0到200，一个创业公司的架构野蛮生长史

贝聊成立于 2013 年，是中国幼儿园家长工作平台，致力于通过互联网产品及定制化解决方案，帮助幼儿园解决展示、通知、沟通等家长工作中的痛点，促进家园关系和谐。贝聊是威创股份（A 股幼教第一股）、清华启迪、网易联手投资的唯一品牌。在短短几年内，用户规模迅速达到千万级别，每年 DAU 均呈倍数级增长。 面对如此快速的发展，原有的技术架构很难支撑越来越复杂的业务场景，在系统可用性以及稳定性方面，都给贝聊技术团队带来了很大的压力。因此，如何针对当前需求，选择合适的技术架构，保证架构平滑演进，值得我们深入思考。

0

Redis Aof&Rdb Persistence Theory

[转]不管你的Redis集群规模有多大，都是时候思考下如何提升资源利用率了

Redis 是互联网产品开发中不可缺少的常备武器，它性能高、数据结构丰富、简单易用，但同时也是因为太容易用了，我们的开发同学不管什么数据、不管这数据有多大、不管数据有多少通通塞进去，最后导致的问题就是 Redis 内存使用持续上升，但是又不知道里面的数据是不是有用，是否可以拆分和清理。 为了更好地使用 Redis，除了对 Redis 做一些使用规范，还需要对线上使用的 Redis 有充分的了解。那么问题来了：一个 Redis 的实例用了那么大的内存，里边到底存了啥？都有哪些 key？每个 key 占用了多少空间？ 雪球当前有几十个 Redis 集群，近千个 Redis 实例，5T 的内存数据，我们也想要分析业务是否有误用，以提高资源利用率。当然，曾经我们也深深地被这个问题所困扰，今天我就来和大家分享下我是如何解决这个问题的，希望能给各位一些启发。