Kafka在0.10版本推出了Stream API，提供了对存储在Kafka内的数据进行流式处理和分析的能力。 本文将从流式计算出发，之后介绍Kafka Streams的特点，最后探究Kafka Streams的架构。

    Facebook 经常使用数据驱动的分析方法来做决策。在过去的几年，用户和产品的增长已经需要我们的分析工程师一次查询就要操作数十 TB 大小的数据集。我们的一些批量分析执行在古老的 Hive 平台（ Apache Hive 由 Facebook 贡献于 2009 年）和 Corona 上——这是我们定制的 MapReduce 实现。Facebook 还不断增加其对 Presto 的用量，用于对几个包括 Hive 在内的内部数据存储的 ANSI-SQL 查询。我们也支持其他分析类型，比如图数据库处理（graph processing）和机器学习（Apache Giraph）和流（例如：Puma、Swift 和 Stylus）。

    今天读了一篇 《守望先锋》架构设计与网络同步 。这是根据 GDC 2017 上的演讲 Overwatch Gameplay Architecture and Netcode 视频翻译而来的，所以并没有原文。由于是个一小时的演讲，不可能讲得面面俱到，所以理解起来有些困难，我反复读了三遍，然后把英文视频找来（订阅 GDC Vault 可以看，有版权）看了一遍，大致理解了 ECS 这个框架。写这篇 Blog 记录一下我对 ECS 的理解，结合我自己这些年做游戏开发的经验，可能并非等价于原演讲中的思想。 Entity Component System (ECS) 是一个 gameplay 层面的框架，它是建立在渲染引擎、物理引擎之上的，主要解决的问题是如何建立一个模型来处理游戏对象 (Game Object) 的更新操作。

    早先使用ik8（netease类的后起之秀），博客中国、新浪博客、百度空间的时候觉得写博客其实这样也还不错：不用自己管理服务器，不用自己写博客程序，不用自己处理域名解析等，而且是免费的，还有基于平台的交流圈。

    在一台机器存不下1个业务所有缓存的时候，一般都会选择分片的策略(大多采用取模的办法)，但有的时候缩减单个缓存对象的大小，也可以节省整个池子的资源： 1、一般情况之下，key的重复度很高，可以选择缩减key的长度； 2、在序列化的时候选择创建slim object，然后JSON.toJSONString()； 3、使用gz/br压缩JSONString (考虑平滑兼容多种压缩方式，使用第一个字节作为标志位)​；

    虽然系统越来越复杂，以及新分布式架构设计的思想普及，越来越多的系统采用了分布式的架构，特别是HTTP为交互方式的接口调用，移动端和PC端的并行对分布式架构带来了很大的推动。各式各样的服务接口，在处理业务流程之外有一些共性的问题，正视设计和解决这些问题，会大大提高程序的可用性，扩展性和可维护性。

    Google已经是一个非常成功的公司。除了Google搜索和AdWords的成功之外，Google还提供了许多其他突出的产品，包括Google地图、Google新闻、Google翻译、Google语音识别、Chrome和Android。 Google还大幅增强和扩展了通过购买小型公司（如YouTube）所获得的许多产品，并对各种开源项目做出了重大贡献。Google已经展示了一些尚未推出的惊人产品，例如自动驾驶汽车。 Google的成功有很多原因，包括开明的领导力，伟大的人才，高招聘标准，以及在迅速成长的市场中成功获利的财务实力。 但其中一个原因是Google摸索出了优秀的软件工程实践，帮助它成功。这些做法随着时间的推移，根据许多最有才华的软件工程师的积累和沉淀的智慧而演变而成。我们想与世界分享我们的做法，并分享我们从错误中学到的一些教训。 本文的目的是整理并简要介绍Google的关键软件工程实践。然后，其他组织和个人可以将它们与自己的软件工程实践进行比较和对比，并考虑是否自己应用这些实践中的一些。 许多作者都有分析Google的成功和历史的书籍或文章。但大多数主要涉及商业、管理和文化；只有那些的一小部分已经探索了软件工程方面的事情，并且大多数只探索一个方面；而且没有一篇文章提供了Google整体软件工程实践的简要概述，正如本文旨在做的那样。

    Springboot 实现 Restful 服务，基于 HTTP / JSON 传输，适用于前后端分离。这只是个小demo，没有加入bean validation这种校验。还有各种业务场景。

    很多使用 Unity3D 开发的项目，都不太喜欢 C# 这门开发语言，对于游戏开发很多人还是更喜欢 Lua 一些。而 Lua 作为一门嵌入式语言，嵌入别的宿主中正是它说擅长的事。这些年，我见过许多人都做过 U3D 的 Lua 嵌入方案。比如我公司的阿楠同学用纯 C# 实现了一个 Lua 5.2 （用于在 U3D web 控件中嵌入 Lua 语言的 UniLua ）；还有 ulua slua wlua plua xlua ... 数不胜数。我猜测，a-z 这 26 个字母早就用完了。 上面提到的项目的作者不少是我很熟悉的朋友，我们公司现在的 U3D 游戏也由同事自己实现了一套差不多的东西。所以我曾了解过这些方案。但我一直觉得这些方案要么做的过于繁琐，要么有些细节上不太完备，总是手痒想按自己的想法搞搞看。

     我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。 那这种问题有什么好办法解决呢？

    在 skynet 中，有时候为一个服务实现一个前置的代理服务是很有必要的。 比如，你希望对这个服务发起的请求是支持超时的，就不必在功能实现的服务中实现，那样会增加无谓的复杂性。你可以在功能实现的服务前加一个代理服务，当超时发生时，通知请求方。关于这个实现，我在 blog 中给过一个示例。 同理，当你需要做一些负载均衡的处理的时候，也可以做一个代理服务，让请求分摊到多个可以完成类似功能的服务中去，实现比较简单，本文就不展开了。 今天想谈一下怎么利用代理服务更好的为一些热点服务提供过载保护。

    2010年的时候，我们开始最早的一波做小米的服务器的同学，基本都很少互联网经验，七拼八凑的把米聊上了线，这么多年过去了，很多技术框架沉淀到了公司各处团队中去了。 今天再来看，其实有很多细节，当时真的没考虑（现在也是坑）。

    最近工作中一直和SWF（Amazon的Simple Work Flow）打交道，在一个基于SWF的工作流框架上面开发和修bug。SWF的activity超时时间是5分钟，在activity task开始执行以后，activity worker需要主动发送心跳请求告知service端：“我还活着，我还在干活”，如果出现超过5分钟（可以配置）没有心跳，SWF的service端就认为，你已经挂了，我需要把这个activity安排到别的activity worker上来执行了。借用AWS官网的一张图：

    对于刚创业的团队，资金和人才配备没有成型的大公司充分，因此在技术选型上须充分思考。本文针对后端语言选择问题作出分析，不会涉及到语言优劣问题，笔者认为语言遵循优胜劣汰规则，能够继续生存下来的语言都是好的语言，只是各自适合解决不同的问题。

    ReDex 是 Facebook 开源的工具，通过对字节码进行优化，以减小 Android Apk 大小，同时提高 App 启动速度。

    ​在前端开发中，性能一直都是被大家所重视的一点，然而判断一个网站的性能最直观的就是看网页打开的速度。其中提高网页反应速度的一个方式就是使用缓存。一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。那么下面我们就来看看服务器端缓存的原理。

    API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。 其实对于我们接触的web端开发而说，Api就是协商好的一种规范，大家都按这个规范做事，这里主要针对前&后端交互的接口进行说明～

    无疑Native的动态化能力较Web要弱很多，很多操作是依赖版本节奏的。这就导致在Native App上许多决策无法快速验证，对存在不足的逻辑没办法快速修正。受到这些条件的限制，那个唯快不破的铁律在Native App上遭遇到了尴尬。每一个产品决策会变得异常谨慎，因为一个错误的决策要持续整个版本周期可能被修复。慢慢的我们就会发现，不出错会成为做出决策的重要因素，而有意义却退居二线。 所以具备快速验证和及时修正这两个能力就显得非常重要，打造这样的能力需要一个完整的解决方案。我们认为，这个方案是一个以A/B测试为核心，结合周边多个系统能力，共同组成的一个试错平台。在这个平台上，我们的团队，不管是业务方还是工程师，都可以快速应变，不畏惧出错，变得灵动起来。

    由于 React 的单向数据流的设计，衍生出了单向数据流的架构模式 Flux。 在 MVC 的分层架构中，Flux 属于 M 层，也就是 Model，而在 Flux 中，Store 是关键部分，Action 和 Dispatcher 都是围绕着 Store 来设计的，所以 Flux 架构模式的目标就是基于单向数据流如何更好的管理数据，在 Views 或 Controller-views 与数据之间进行解耦。

    其实，分布式系统说白了，就是很多机器组成的集群，靠彼此之间的网络通信，担当的角色可能不同，共同完成同一个事情的系统。