无处不在的C/S架构

在这个充斥着云的时代,我们使用的软件可以说99%都是C/S架构的！

• 你发邮件用的Outlook,Foxmail等
• 你看视频用的优酷，土豆等
• 你写文档用的Office365,googleDoc，Evernote等
• 你浏览网页用的IE,Chrome等(B/S是特殊的C/S)
• ......

C/S架构的软件带来的一个明显的好处就是：只要有网络，你可以在任何地方干同一件事。

例如：你在家里使用Office365编写了文档。到了公司，只要打开编辑地址就可以看到在家里编写的文档，进行展示或者继续编辑。甚至在手机上进行阅读与编辑。不再需要U盘拷来拷去了。

C/S架构可以抽象为如下模型：

• C就是Client(客户端),上面的B是Browser(浏览器)
• S就是Server(服务器)：服务器管理某种资源，并且通过操作这种资源来为它的客户端提供某种服务

C/S架构之所以能够流行的一个主要原因就是网速的提高以及费用的降低，特别是无线网络速度的提高。试想在2G时代，大家最多就是看看文字网页，小说什么的。看图片，那简直就是奢侈！更别说看视频了！

网速的提高，使得越来越多的人使用网络，例如：优酷，微信都是上亿用户量，更别说天猫双11的瞬间访问量了！这就对服务器有很高的要求！能够快速处理海量的用户请求！那服务器如何能快速的处理用户的请求呢？

"书籍收藏家"

你是否有过这样的经历？

亦或，终于读完了一本书！这本书讲的什么呢？呃。。。。

我在很长一段时间里都有这样的困惑！这种情况导致的结果是，我成了"书籍收藏家"---买的书里没读完的比读完的多得多！

用户体验

作为互联网从业人员，经常会接触到“用户体验”这个词！ 我们可能为了一个菜单该放在哪里而争论，或一边苦逼的编码一边骂着SB产品经理！ 我们为别人考虑着“用户体验”，但是对自己一直在用的软件，为什么却这么将就呢？

软件=工具

作为软件开发人员，使用的软件不在少数，我们都称为工具。即为工具，我们好像就不那么纠结难不难用了！好像工具就应该比较难用才对！而实际上，我们为别人做的软件，对别人来说也是工具。我们为什么要为用户考虑这么多，为什么不为自己考虑考虑？

现在，我们从用户体验的角度重新审视下我们常用的工具！

简单

在做软件的时候，我们知道要把用户当作“白痴”来看待！要尽可能的把功能做简单，能一步完成的绝对不能分成两步。所以软件要做得足够的简单。但是简单并不代表功能上的简单，比如说Windows下的记事本，那叫简陋！对于工具型软件来说，“简单”有三个层面上的意思：

功能够用

软件功能应该也适用28原则，即在使用软件的大部分(80%，甚至更多)情况下，只会使用很少(20%，甚至更少)的功能。所以软件没必要太多的功能。只要有足够的核心功能即可。过多的功能只会增加软件的复杂度和学习成本。

一个很典型的例子就是Office。Office功能很强大，但是大家大部分情况下会用到它多少功能？有5%吗？而且，你会发现，你需要的功能消失在了它的菜单列表里了！

现在再看Word的工具栏，是什么感觉？

写在前面

听说《人件》是很久之前的事了，但一直没读。主要是受到了《人月神话》的影响---《人月神话》一直被奉为经典管理书籍，名声应该比《人件》高，至少我是这么认为的。所以先读了《人月神话》，当时还很好奇，《人月神话》和项目管理有毛线关系？读了才知道，“人月”就是我们说的“人天”！读了大概三分之一，不知道是翻译问题还是作者行文方式不适合我，反正读不下去了，感觉说了那么多废话只是说明了“增加人力无法加快项目进度”！所以《人件》也就无限期搁置了！

最近项目组购书，买了这本书，就拿来看看！看了才有一种相见恨晚的感觉。我做了两年多的管理，最近不想做了，又回到了技术。这本书并没有让我学到什么，但是它所提到的很多内容和我当时的管理方式很契合，或者说和我的想法很相近，同时也解释了我最后为什么不想做管理了！

人员管理

“流水的开发，铁打的项目”。相信对有几年经验的开发人员来说，这句话并没有说错。

很庆幸的是，在我管理的两年多里，没有人离职，虽然团队不大，只有七个人。

我把功劳归结为：

• 项目组成员的自觉性
• 和我的好脾气

而《人件》给了我更有说服力的说法：“管理者不是让大家去工作，而是创造环境，让大家可以顺利的开展工作”

• Luminus手册

• 语言与模式

简介

最近研究Docker，由于Docker由golang编写，为了更好的梳理Docker，所以先过了一下golang。

其实之前看过golang，对其语法无爱，所以就没太关注。

这次先简单梳理一下个人感觉比较有新意的地方！

less is more

golang推崇少即是多理念，语法简单，关键字就20多个，半天过一遍语法绰绰有余！

相对的Java关键字近100个，死板的语法，一堆的模板代码，这也是Java一直被喷的地方！

PS:要说"少即是多"理念的话，应该首推Lisp，比如Clojure,关键字不超过10个，其它功能全部是在这几个关键字上实现的，且语法高度统一

就看最简单的Hello World就行了

//java实现
public class Hello{
    public static void main(String[] args){
        System.out.println("Hello World");
    }
}

//go实现
package main
import "fmt"
func main() {
    fmt.Println("Hello World")
}

;clojure实现
(println "Hello World")

就HelloWorld这个例子看，golang和Java算是半斤八两!对比可以看出如下几个区别:

• golang不是面向对象语言，所以不是基于类和对象来构建代码的
• golang不像Java会默认导入例如java.lang包，需要手动import
• golang的启动方法也叫main，不过没有参数，且这个方法必须要在main这个包里
• golang没有访问权限控制符，它的访问控制是靠大小写来控制的(看到这你能理解为什么Println的P要大写了吧?)

场景

单机应用已经越来越不能符合目前越来越复杂的产品需求了。即使是小型应用，至少也需要部署2台以上的服务器做集群。且应用必须24小时对外服务,可用性得达到n个9。这就对发布有了更高的要求。

也就催生了灰度发布这样的发布过程。而即使是这样，还是需要经历大致如下的发布过程:

• 下载代码
• 打包
• 停止服务器
• 部署
• 启动服务器

而业界一直诟病JVM的启动速度，再加上如果项目比较大，编译过程比较长，发布机器比较多，那么做一次完整的发布可能需要几个小时。万一中途出了问题，要回退，又要几个小时。

是否可以解决这样的问题呢？而OSGi恰是一个不错的选择!

OSGi

OSGi是一个优雅、完整和动态的组件模型，提供了完整的模块化运行环境。

应用程序（称为bundle）无需重新引导可以被远程安装、启动、升级和卸载。

其主要应用在嵌入式开发中，而在JavaSE和JavaEE方面则少有建树。其最著名的使用就是eclipse了。究其原因主要有:

• 增加开发难度：需要开发人员更关心模块的划分，处理模块与模块之间的依赖关系(模块间的导入导出),这是一个好的方面，但是
• 没有完善的工具：模块间的依赖关系需要开发人员手动处理(有相应的工具，但不能百分百处理依赖关系)。
• 额外的运行环境：应用(bundle)需要运行在实现了OSGi规范的容器内，导致了模块间的依赖关系需要在运行时才能验证是否有问题。也就是说无法在编译期验证模块间的关系。同时也增加了测试及调试的难度。

可以看出，OSGi的主要缺点是开发较繁琐。而针对前面所提到的问题，OSGi解决了如下几个问题:

• 项目模块化，对于项目的更新与发布不再需要发布整个项目，只需要发布需要更新的模块即可。提高了编译打包的速度。
• OSGi可在运行时的对bundle进行安装、启动、升级和卸载。提高了部署的速度。(这里就需要吐槽一下eclipse了，它是基于osgi的，但是每次安装插件都要重启是要搞哪样？！)
• 支持多版本发布。在OSGi容器内可发布相同应用的不同版本

OSGi是如何做到这些的呢？其实OSGi实现了一套自身的ClassLoader，具体可见此文

OSGi容器

目前OSGi容器主要有Knopflerfish, Apache Felix, Equinox, Spring DM。其具体比较请见此文

以及其上的一些应用，方便在OSGi上进行开发，比如Karaf,ServiceMix等。