徐靖峰的专栏

服务组件化组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。在“微服务”架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过http等通信协议进行协作，而不是传统组件以嵌入的方式协同工作。服务都独立开发、部署，可以有效的避免一个服务的修改引起整个系统的重新部署。打一个不恰当的比喻，如果我们的PC组件以服务的方式构建，

介绍好的开发规范不仅能够使得项目变得易维护，易升级。一些通用的规范可以参考《阿里巴巴java开发手册》 本文档主要针对我们现在使用的框架提出一些开发规范，欢迎补充包结构规范以短信邮件项目（mail-sms）为例，介绍包结构命名规范。 短信邮件项目主要包含短信，邮件两个子模块【强制】 包分层–通用 一般每个项目都包含下面六个模块，还有一些各自扩展的模块 1. api #a

介绍Zipkin 为一个分布式的调用链跟踪系统( distributed tracing system ) ,设计来源于 google dapper paper官方网站 http://zipkin.io/快速入门安装方式一：使用zipkin官方提供的jar启动服务 zipkin官方提供了一个现成的使用springboot写的zipkin服务端，客户端的链路监控报告可以通过多种方式（下文会讲

功能需求：设计一个秒杀系统初始方案商品表设计：热销商品提供给用户秒杀，有初始库存。@Entitypublic class SecKillGoods implements Serializable{ @Id private String id; /** * 剩余库存 */ private Integer remainNum; /**

时下很多企业应用更新换代到分布式，一篇文章了解什么是RPC。 原作者梁飞，在此记录下他非常简洁的rpc实现思路。/* * Copyright 2011 Alibaba.com All right reserved. This software is the * confidential and proprietary information of Alibaba.com ("Confident

前言控制并发的方法很多，我之前的两篇博客都有过介绍，从最基础的synchronized，juc中的lock，到数据库的行级锁，乐观锁，悲观锁，再到中间件级别的redis，zookeeper分布式锁。今天主要想讲的主题是“根据并发出现的具体业务场景，使用合理的控制并发手段”。业务场景修改个人信息修改商品信息扣除账户余额，扣减库存业务场景分析第一个场景，互联网如此众多的用户修改个人信息，这算不算

最近正在为本科论文的事感到心烦，一方面是在调研期间，发现大部分的本科论文都是以MVC为架构，如果是使用了java作为开发语言则又是千篇一律的在使用SSH，二方面是自己想就微服务，分布式方面写一篇论文，讲述一些技术点的实现，和一些中间件的使用，看到如八股文般的模板格式..不免让人望文生怯。退一步，投入模板化ssh-web项目的怀抱，落入俗套，可以省去自己不少时间，因为在外实习，琐事并不少；进一步，需要