Starlight36's Blog爱生活，爱Coding。菜单跳至内容首页编程技术系统/应用乱七八糟关于我基于Twitter的Snowflake算法实现发号器在微服务架构的系统中，ID号的生成是一个需要考虑的问题。通常单体系统会依赖RDB的自增字段（例如MySQL）或者序列（例如PostgreSQL等）来产生业务序号。在微服务架构的系统中也使用类似的方式时就会出现一些问题。在单体系统中，我们可能会使用自增字段，或者序列，它们通常依赖于关系型数据库插入动作时产生的ID。不过由于ID是在持久化到数据库时才产生，所以我们无法提前获取一个ID号。对于单体系统而言并没有什么问题，但当存在多个系统协作时，我们可能希望提前生成业务的ID号，以保证业务可以以幂等的方式进行操作。为了解决这个问题，ID生成可以先独立出单独的模块，每次产生一个新的ID号供业务方使用。不过利用RDB的序列（MySQL可以模拟一个序列）来进行发号，通常存在性能瓶颈。因为业务操作必须先在RDB操作后，才能取得新的ID号。一旦RDB是单点系统，那么所有业务的可用性都会受到影响。另外连续的ID号可能会暴露业务的信息，通过ID号可以间接地刺探到业务的规模，也更容易受到攻击，一旦存在权限验证不严的系统，攻击者可以轻而易举的枚举全部的信息访问。UUID是一种专门设计用来在分布式系统中生成ID的工具。它可以产生一个128bit的ID号。目前常见的版本是v1和v4，其中v1版本使用时间戳、MAC地址、随机数来生成一个ID号，v4版本使用随机数来产生ID号。但是UUID通常情况下过于冗长，存储为一个32+4个字符串，作为业务ID使用并不方便，另外UUID依然存在冲突的可能性，只不过这种可能系非常低。使用UUID用做分布式系统的ID生成器是一种选择，但是更多时候我们希望ID号可以：生成高效，可分布式并行发号大致时间顺序（对于数据分片、排序友好）稀疏不连续可以使用64bit整型存储可预见的时间范围内不重复Twitter开源了他们的ID生成器，被称作snowflake，项目地址在https://github.com/twitter/snowflake。不过目前Twitter已经完全重写了他们的发号器，因此这个项目现在处于关闭状态，参考源代码只能查看2010年的初始tag，目前也不再维护这个项目了。继续阅读 →本条目发布于2017 年 2 月 3 日。属于编程技术分类，被贴了 发号器 标签。作者是starlight36。爱油科技基于SpringCloud的微服务实践摘要本次分享主要介绍了爱油科技基于Docker和Spring Cloud将整体业务微服务化的一些实践经验，主要包括：微服务架构的分层和框架选型服务发现和配置管理服务集成和服务质量保证基于领域驱动设计实施DevOps继续阅读 →本条目发布于2016 年 12 月 8 日。属于编程技术分类，被贴了 docker、Spring、微服务 标签。作者是starlight36。Restful中PUT和POST的区别在编写Restful风格服务时经常搞混PUT和POST方法，只是隐隐约约记得一个用于创建一个用于更新，但是对这个并不是特别确定，今天正好确认一番。爆栈网有一个回答很清晰：对于PUT和POST而言，他们都可以用来创建资源。那么到底哪一个应当使用呢？通常考虑以下点：如果你在请求时指定资源ID，那么用PUT；你期望服务器自动生成资源ID，那么用POST；PUT是幂等的，重复调用两次不会造成额外的影响，所以PUT可以被安全的重试；PUT可以用来更新或者创建资源；POST方法在同时访问时，可能会修改一个资源对象的不同部分。原问题：http://stackoverflow.com/questions/630453/put-vs-post-in-rest本条目发布于2016 年 9 月 12 日。属于乱七八糟分类。作者是starlight36。[翻译]为Kubernetes创建自定义Pod水平扩展器原文链接：Building your own horizontal pod autoscaler for Kubernetes当前版本（1.3）的Kubernetes为在生产环境中平滑运行容器化应用提供了大量开箱即用的特性。不过一些特性依然不够完善，比如Pod水平扩展器（Horizontal pod autoscaler, HPA）。现在你只能根据CPU和内存使用水平进行扩容调度，自定义指标的调度目前仅在Alpha版本中支持。我们其中一个应用是一个Websocket服务器，用来处理来自客户端的长连接。然而性能测试显示我们的应用最大可以承载大约25000个Websocket活跃连接，更多的连接数会导致服务器不稳定甚至崩溃，然而这时通常不会引起CPU负载的升高和内存开销的增长。所以让Kubernetes根据Websocket连接数进行扩展调度的需求应运而生。本文介绍了我们创建自定义水平扩展器（HPA）的一些实践。继续阅读 →本条目发布于2016 年 8 月 20 日。属于系统/应用分类，被贴了 Kubernetes、翻译 标签。作者是starlight36。HTTP/2升级小记最近H5被插广告愈演愈烈，于是打算给H5增加HTTPS支持。既然都支持了HTTPS，那么HTTP/2也就顺便来支持一下好了，反正SSL证书已经不是问题了。我们是全容器环境，包括前端机在内，全部跑在容器里，更新前端nginx容器配置即可。Nginx从1.9.5版本开始支持HTTP/2的，查了一下满足条件。从HTTPS到HTTP/2，只需要：server {listen 443 ssl http2;}123server {    listen 443 ssl http2;}即可。但是会有一些问题。协议协商包括NPN和ALPN两种，NPN是SPDY时代的产物，HTTP/2定稿时已经被ALPN取代。我们的目标是支持HTTP/2，因此务必支持ALPN。 继续阅读 →本条目发布于2016 年 8 月 17 日。属于系统/应用分类。作者是starlight36。[翻译]如何在Docker中使用Open vSwitch创建跨主机的容器网络翻译自原文：http://openvswitch.org/support/dist-docs/INSTALL.Docker.md.txt本文介绍了如何使用Open vSwitch为Docker 1.9.0及以后版本提供网络支持。操作前请先确认你已经按照[INSTALL.md] 编译，或者通过包管理器安装了Open vSwitch。关于如何安装Docker，请参考www.docker.com上提供的介绍。Docker从1.9.0版本之后提供了跨主机的网络支持。通过将Docker和Open vSwitch整合，则可以利用Open vSwitch virtual network (OVN)进行互联互通。继续阅读 →本条目发布于2016 年 4 月 9 日。属于系统/应用分类，被贴了 docker 标签。作者是starlight36。PHP设计模式的分享在新浪微博时分享的PH