【吴钩】如果将中华帝国想象成一个大公司（汉唐篇）
【吴钩】如果将中华帝国想象成一个大公司（汉唐篇）
作者：吴钩阅读数：1749发表时间： 20:54:32
作者简介：吴钩，男，西历一九七五年生，广东汕尾人。历史研究者，认同儒家宪政主义。著有《隐权力：中国历史弈局的幕后推力》（云南人民出版社，2010年），《隐权力2：中国传统社会的运行游戏》（复旦大学出版社，2011年），《重新发现宋朝》（九州出版社2014年)，《中国的自由传统》（复旦大学出版社2014年），《宋：现代的拂晓时辰》（广西师范大学出版社2015年）。
如果将中华帝国想象成一个大公司（汉唐篇）作者：吴钩来源：作者授权 儒家网发布& & & & & 原载于“我们爱宋朝”微信公众号时间：孔子二五六八年岁次丁酉五月十九日辛未& & & & &耶稣日&&&如果我们将“家天下”时代的郡县制帝国想象成公司，那么它显然是一个巨型的家族企业，用明末大儒黄宗羲的话来说，帝王“视天下为莫大之产业，传之子孙，受享无穷”。皇室是这个家族产业的唯一股东，皇帝为董事长，宰相则是皇帝聘请的CEO，率领一个由官僚组成的职业经理人团队替皇上打理天下。这样的权力框架，在秦汉时已经成型。&略去二世而亡的秦朝不计，汉帝国是“家天下”时代第一个将家族产业维持了百年以上的长命王朝。我们的故事也从汉代说起。&&&汉代：外戚与宦官轮流专政&汉武帝后元二年（公元前87年），汉帝国最具雄才大略的“董事长”刘彻去世，将庞大而危机暗伏的刘氏家业，留给八岁的幼子刘弗陵（即汉昭帝）。在快要走到人生尽头的时候，刘彻做了两件事：其一，杀了刘弗陵之母钩弋夫人，因为这位铁腕帝王不希望在他死后，由于“主少母壮”，出现母后临朝、败坏朝纲的局面；其二，任命外戚霍光为“大司马大将军”，辅弼幼帝刘弗陵，这里显示了刘彻对以宰相为首的官僚集团的深度不信任，担心日后若无亲贵辅佐年幼的皇帝，将会发生皇权旁落的情况。&汉武帝是一个对独裁权力具有特别嗜好的皇帝，他当然不打算跟其他人分享统治汉家天下的权力，更不打算当一名垂拱而治的“甩手掌柜”。本来汉朝在缔造之初，尚谈不上是一个绝对集权的帝国，高祖刘邦除了保留秦代的郡县制，还局部实行分封制，封国与郡县并存。封国有如母公司（帝国中央）旗下的子公司，具有法人资格，拥有自己的董事会以及独立的财政、行政权力；郡县则如同总公司派出的不具备独立地位的分公司。&而在帝国中央，另有分权，即皇室与政府分化，皇室下面有一个小型的办事机构，叫做“六尚”，即尚冠、尚衣、尚食、尚沐、尚席、尚书。从其名字就可看出，“六尚”处理的只是皇帝的私人事务，只处理内廷事务；政府则由“三公”（丞相、太尉、御史大夫）领衔，下设九卿、十三曹，处理全国政务。因此，我们不妨说，皇帝只是主权象征，拥有帝国的所有权，但国家政务却由宰相（CEO）执掌。宰相的权力非常大，“辅翼国家，典领百僚，协和万国”，都是宰相的职权。&皇室与政府的分化，是国家治理结构成熟化的标志。但这个分权的治理结构并不牢固，如果皇帝不甘心垂拱而治，则很容易出现所谓的君权与相权之争，换句话说，就是产权所有人与经理层之间发生或明或暗的权力争斗。这一权力争斗几乎贯穿了二千多年的“家天下”历史，并触发了帝国政制的一系列变动。本文想剖析的所谓“身边人控制”也是由此产生。&汉代的“身边人控制”在武帝时代已露端倪。&雄才大略的刘彻在当上汉帝国总公司的“董事长”之后，决心收回被子公司与CEO分走的权力，加强公司总部与董事长本人的权势。一方面，他以“推恩令”彻底瓦解了封国的实力，又派遣“部刺史”分巡天下，强化中央对群县的管控。另一方面，他创设“内朝”，任用尚书、中书、侍中、中常侍等皇帝身边的亲信、近臣（即皇室“身边人”），组成一个非正式的顾问与决策班子，架空外朝宰相之权。自此帝国中央便有了内朝、外朝之分。&法理上，外朝是帝国正式的管理队团，行使的是法定权力；内朝只是皇帝的私人班子，并无治理国家的职权，但因为内朝诸人受到皇帝宠信，得以预闻政事，因而获得了一种有实无名的、非正式的权力，我称之为“隐权力”。内朝的隐权力极大，可以与外朝分庭抗礼，甚至凌驾于外朝之上，宰相徒具名分而已。&这种现象，就是“身边人控制”。由于皇帝“身边人”的隐权力缺乏名分上的合法性，只能完全附依于皇帝私人的关系网络上，当然要对皇帝惟命是从。于是通过对内朝的驾驭，刘彻成功撇开外朝宰相，实现了君主独裁。&汉武帝是个魅力型领袖，驭下有术，在他治下，“身边人”尚不致带来严重的问题。刘彻肯定也设想过“身边人控制”的副作用，他去世前狠心杀了钩弋夫人，就是要防止这名新皇帝最亲近的“身边人”擅权乱政。但是，刘彻似乎更不愿意看到CEO团队借着新皇帝年少无知之机，侵占董事长之大权，所以他又命外戚霍光为“大司马大将军”，统领内朝。&刘彻始料不及的是，时过境迁，原来完全依附于皇权的“身边人”，也会变得位高权重，不但不受人主控制，甚至威胁到皇权的安全。如常由外戚充任的“大司马”，在武帝时代只是内朝官，并无印绶、官属，但大司马挟外戚（皇室“身边人”）的权势，逐渐夺得统率政府的正式权力，到了西汉末期，大司马已成为外朝“三公”之首，位极人臣，权倾朝野。最终葬送西汉政权的大司马王莽，恰恰也是外戚。这便是“身边人控制”的恶果。&王莽的新朝极其短命。光武帝刘秀继承汉祚，建立东汉政权，鉴于之前大司马篡权的乱象，刘秀设“尚书台”架空“三公”之权，一切政令皆经尚书台禀陈皇帝，由皇帝裁决，时人称“虽置三公，事归台阁”，“三公之职，备员而已”。“台阁”即尚书台。刘秀重用尚书台，不过是模仿刘彻故智，用的还是“身边人控制”这一招。我们从字面上就可以理解，“尚书”本是皇室秘书的意思，协助皇帝整理文书，身份卑微，很方便皇帝控制、指挥，现在刘秀将尚书扩充为尚书台，作为皇帝的办事机构，以此架空宰相的权力，尚书也就获得了巨大的隐权力。在光武帝时代，“身边人”尚不致乱政，但钱穆先生说，这只是人事好，而不是制度好。&很快，“身边人控制”的恶果又爆发了。东汉后期，由于皇帝多是幼年登基，免不了出现母后柄权的情况，于是太后的“身边人”——外戚常常以“录尚书事”之衔入主尚书台，把持朝政。尚书也演变成为“出纳王命，敷奏万机，盖政令之所由宣，选举之所由定，罪赏之所由正”的权力中枢，而不再是皇帝的附庸。小皇帝成年之后，要夺回权柄，手法还是模仿乃祖，另行扶植宠信的“身边人”，只不过这时的“身边人”换成了宦官。而宦官得势之后，又复擅权乱政。东汉后期的政局，基本上就是外戚、宦官两批“身边人”轮流专政。&后来东汉产业被门阀世族瓜分、颠覆，中国进入近四百年之久的战乱周期，直至李渊建立大唐政权，才迎来一个较长时段的承平之世。&& &&唐代：内相擅权，宦官乱政&现在说到唐朝。在大唐“李记公司”内，董事长换成了李氏皇帝，CEO团队的权力分配也发生了变化——宰相的权力一分为三，由中书省颁发政令；门下省主复核，如不同意政令，有权“封驳”；尚书省则执行命令。中书、门下、尚书在汉代时都属于皇室私臣，现在却成了政府的正式首脑，即李记公司的CEO，当然也就不再是皇帝“身边人”了。&汉代出现的产权所有人与经理层之间的权力争斗，在唐代依然存在。为了避免CEO团队坐大、摆脱控制，李唐王朝的“董事长”所想到的招数还是起用“身边人”。首先受到李氏皇帝青睐的“身边人”是翰林学士。&翰林学士本来是由皇室供养的伎艺人员，以供皇帝随时“召入禁中驱使”，就如企业的老板出钱养了一班闲人，有事时让他们提提建议，无事时则叫来下下棋。在唐高宗时代，皇帝已经常常将几个亲密的翰林学士召入宫中，“密与参决时政，以分宰相之权，时谓‘北门学士’”。唐玄宗即位后，于开元二十六年（公元738年），置立学士院，专掌内廷命令，标志着唐代“身边人控制”的制度化。&此后，凡拜免将相、号令征伐、立皇后、定太子等重要诏书，都由翰林学士起草，用白麻纸书写，直接从禁中发出，叫做“内制”；而中书省起草的文件，则用黄麻纸书写，称“外制”。翰林学士也因此有了“内相”之名。显然，皇帝是要以近臣（身边人）来削弱外臣（CEO团队）的职权。&翰林学士毕竟是饱读诗书的儒士，掌权后尚不致于胡来，但这依然是因为人事不坏，而不是因为制度好。另一类“身边人”——宦官一旦窃取了隐权力或正式权力，情况就不一样了。唐代宦官在李世民时代只是“门阁守御，廷内扫除，廪食而已”，但安史之乱后，皇帝因猜疑武将而宠信宦官，宦官不仅掌握内廷机要，而且侵入外朝系统，担任政府要职。&皇帝的本意是要扶植一个“身边人”班底来牵制CEO团队，防止权柄下移，但是“身边人控制”就如一道不可逆的程序，一经启动即无法制止，到后来，宦官权势越来越大，以至于“迫肋天子，下视宰相，陵暴朝士如草芥”，不但CEO团队的权力被架空，不少翰林学士也成了宦官的鹰犬，就连皇帝的生杀废立，都操在宦官手中。&唐代的皇帝不是想以“身边人”钳制CEO队团、从而达到大权集于董事长一身的目的吗？但是他们低估了“身边人”领悟权术的智力。我们发现唐代的宦官还发展出一套窃取隐权力的理论——晚唐时，有一个叫做仇士良的大宦官总结说，不可让皇帝有闲暇，皇帝一有闲暇就会读书、接近儒臣，这样一来，“吾属恩且薄而权轻矣”；所以，要设法让皇上沉溺于声色犬马，与外臣隔绝，不理朝政，如是，则“万机在我，恩泽权力欲焉往哉”。&仇士良的这套隐权力理论是从自己的实践中总结出来的，很有实用性，他弄权期间，“杀二王、一妃、四宰相，贪酷二十余年”，而“恩礼不衰”。皇帝以为“身边人”更容易控制，但结果反被“身边人”操控于股掌之中。&本来汉代、唐代均已形成了比较成熟的“公司治理”结构、制度化的权力运作机制，即董事长与CEO团队各安其位，董事长作为公司所有人，把握重大决策权，公司的日常治理，则交给专业的CEO团队，用宋代一位官员的话来说，“权归人主（董事长），政出中书（CEO），天下未有不治”。但雄猜之主常常猜疑经理人集团，意欲万事由自己一个人说了算，为了侵夺CEO之权，任用“身边人”组成一个非正式的班底。但结果，“身边人”总是在得势之后坐大，掉过头来反噬董事长之大权。&纵观汉唐二代出现的“身边人控制”及其恶果，我们可以获得一个启示：治理一个庞大的组织，制度重于人事。跟建立在成熟治理结构、制度化运作的CEO团队相比，完全依赖于人事的“身边人”更容易失控，更不可靠。&责任编辑：柳君
以下是来自新浪微博的实时交流动态
&copy 儒家网更多频道内容在这里查看
爱奇艺用户将能永久保存播放记录
过滤短视频
暂无长视频（电视剧、纪录片、动漫、综艺、电影）播放记录，
按住视频可进行拖动
&正在加载...
把视频贴到Blog或BBS
当前浏览器仅支持手动复制代码
视频地址：
flash地址：
html代码：
通用代码：
通用代码可同时支持电脑和移动设备的分享播放
收藏成功，可进入查看所有收藏列表
方式1：用手机看
用爱奇艺APP或微信扫一扫，在手机上继续观看：
方式2：一键下载至手机
限爱奇艺安卓6.0以上版本
使用微信扫一扫，扫描左侧二维码，下载爱奇艺移动APP
其他安装方式：手机浏览器输入短链接http://71.am/udn
下载安装包到本机：&&
设备搜寻中...
请确保您要连接的设备（仅限安卓）登录了同一爱奇艺账号 且安装并开启不低于V6.0以上版本的爱奇艺客户端
连接失败！
请确保您要连接的设备（仅限安卓）登录了同一爱奇艺账号 且安装并开启不低于V6.0以上版本的爱奇艺客户端
部安卓（Android）设备，请点击进行选择
请您在手机端下载爱奇艺移动APP（仅支持安卓客户端）
使用微信扫一扫，下载爱奇艺移动APP
其他安装方式：手机浏览器输入短链接http://71.am/udn
下载安装包到本机：&&
爱奇艺云推送
请您在手机端登录爱奇艺移动APP（仅支持安卓客户端）
使用微信扫一扫，下载爱奇艺移动APP
180秒后更新
打开爱奇艺移动APP，点击“我的-扫一扫”，扫描左侧二维码进行登录
没有安装爱奇艺视频最新客户端？
爸爸去哪儿2游戏 立即参与
30秒后自动关闭
王心凌演唱会热力开唱 着性感服饰与歌迷大跳贴面舞
你可能还想订阅他们：
播放量数据：快去看看谁在和你一起看视频吧~
Copyright (C) 2017
All Rights Reserved
您使用浏览器不支持直接复制的功能，建议您使用Ctrl+C或右键全选进行地址复制
安装爱奇艺视频客户端，
马上开始为您下载本片
5秒后自动消失
&li data-elem="tabtitle" data-seq="{{seq}}"&
&a href="javascript:void(0);"&
&span>{{start}}-{{end}}&/span&
&li data-downloadSelect-elem="item" data-downloadSelect-selected="false" data-downloadSelect-tvid="{{tvid}}"&
&a href="javascript:void(0);"&{{pd}}&/a&
选择您要下载的《》剧集：
您使用浏览器不支持直接复制的功能，建议您使用Ctrl+C或右键全选进行地址复制基于osgi开发大型的企业应用 - skydream - ITeye技术网站
博客分类：
&&& 前端时间认真的学习了一下osgi相关的知识，个人感觉是非常的不错。
&&& 但是看了一下目前osgi的时候，几个成功案例都是基于osgi开发ide，比如eclipse之类。还没有看到用于企业应用的成功案例，是osgi不适合开发企业应用？还是说，目前没有人这样开始使用osgi？或者只是我孤陋寡闻，其实大家已经用开了？
&&& 顺便说明一下为什么有这种的疑问，这个要冲java开发application的方式说起，我接触过的无非是两种：
&&& 1. 简单的j2se的application
&&&&&&& 就是自己写代码，编译打包，然后写一个命令行脚本或者shell，通过java 和main class启动java进程，里面爱干嘛干嘛。
&&&&&&& 好处是简单，小巧，灵活，没有额外的负载。缺点嘛，没有模块化的支持，想安装，卸载，启动，停止，更新其中部分功能时，完全没辙，只能整个退出，更新之后重启启动。不过对于小程序倒不是问题，大型系统就不大可能了。
&&&&&&& 这个是轻量级的解决方法。
&&& 2. 大而全的app server
&&&&&&& 这个就是标准的j2ee，weblogic，glassfish，jboss之类的都是了，提供标准的j2ee容器，完整的j2ee支持，诸如ejb之类，总之什么都有了。自己写代码，打包为app，通过ear，war等方式发布，对其中的任何一个app，安装，卸载，启动，停止都是可以通过控制台搞定的。
&&&&&&& 很强大，但是很“重“，非常的重，像我在的团队，目前开发的东东，启动起来什么不跑就吃了1g内存......
&&&&&&& 这个方案会带来一个问题，当模块被打包在不同ear中时，无法使用java的方法调用，只能通过ejb，或者自己开端口等方式进行远程调用。效率方面不好，而且感觉也挺傻的：同一个机器同一个进程，彼此直接访问还要走远程......在weblogic上可以通过将功能模块打包在同一个ear中，开启 ejb的local call优化为本地访问，但是限制是只能在一个ear中，这又破坏了模块化。
&&&&&&
&&& 从个人爱好和经历来说，我喜欢第一种方式的轻巧，比较讨厌2的笨重。但是1的缺点也很明显，当程序大到一定程度，功能模块越来越多的情况下，就不适用了。上面的例子，那个启动就吃1g内存的家伙，它的java project现在都超过200个了，可以想象有多大吗？如果用1的方式来开发，根本不可能啊。
&&& 再有就是个人审美观的问题，我这个人生性比较反感庞大而复杂的东西，可以说j2ee 容器/ejb(尤其是ejb3.0以前)是完全违背我的美感的，虽然我现在靠这个吃饭，恩，似乎有点偏激......
&&& 所以现在想看看有没有第三条路可以走(恩，当然工作方面2是肯定无法避免的了)，我自己现在想到解决方案就是基于osgi，将不同的功能模块划分为不同的 bundle（当然可以继续按照service细分）。这就避免了1原有的最大不足：无法划分模块来适用和管理，同时也绕开了app server这个大块头。
&&& 稍后准备按照这个思路来开发一个application来练练手，试试可行性如何。比较看好这个思路的前景，但是目前没有信心，呵呵，主要是没有看到类似的案例，不知道该怎么着手，更别提什么最佳实践之类的可供参考。
&&& 颇有摸石头过河的感觉，有朋友可以帮忙指点一二吗？网上可以找到的osgi的内容，基本都停留在简单介绍和高度评价上，没有找到实际的可供参考的东西。哪位同学如有osgi方面的知识请不吝赐教，不胜感激啊！
&&& 非常有诚意的希望能有人和我一起深入探讨这个话题，无论是赞成还是反对.
ps: 因为在标题中有“请教”的字眼，被自动转移到问答频道了。我想了一下，我发这个帖子的主要目的还是为了可以找人讨论，而不是一个简单的问答。因此厚颜将请教二字从标题中去除后再发贴一次，
论坛回复 /
(75 / 38823)
liu_swei 写道jnn 写道liu_swei 写道目前国外很多开源的应用服务器都开始转向osgi了，比如：glassfish、jonas、geronimo、spring-dm、spring-osgi、pax-web等，我们目前做的是开发微内核集成框架，用的内核是karaf，karaf是felix的子项目，项目是开源的，大家感兴趣可以申请加入来为国产中间件做一份贡献：
http://www.trustie.net/projects/project/show/loong
不知道你们在Karaf基础上做了哪些改进，我们公司的Fuse ESB也是基于Karaf的，有空可以聊一聊。
我们重构了声明式服务，重构了日志服务，重构了热部署，定义了部署框架，现在可以部署war包，还可以随时扩展新的部署器、定义了协议处理器框架，定义了web容器框架同时集成了tomcat和jetty，并开发了dservice容器、集成opensso、集成数据源事物等等，下一步要重构karaf的内核
目前我们开源的只是微内核框架，以后会陆续开源所有的源码！
不知道你说的重构主要做了那方面的工作。
据我所知你上面提到的大部分功能 都是由karaf是通过pax－xxx 来实现的。
dservice容器、集成opensso、集成数据源事物， 这几个功能到是有点意思。
我现在有个问题就是如果Karaf升级了，你们的微内核框架需要做多大的修改才能使用新版本的Karaf.
呵呵，我们的重构更多的是功能上的，至于karaf内核，我们正准备重写它的内核
这样就不必依赖于它了，至于集成的jetty我们最初采用的的确是pax-web的，后来为了集成tomcat我们自己定一个了web容器框架，并重新集成了jetty，已经完全和pax-web无关了。
pufan 写道skydream 写道&&&& 再次更新，分成3个层次
老兄，service定义bundle在哪里，你这样做common bundle怎么能够热插拔？
对于热拔插的支持，我个人感觉在business bundle这个层面上比较有可能有需求，对于common bundle，似乎实际意义不大。
打个比方说，有一个短信网关之类的应用，在business层面上，增加，卸载或更新某个业务能力是可能的，比如对smpp sms模块的更新，增加一个rest方式的sms模块，这个热拔插请求是比较合理的。对于common层，我不大理解为什么需要热拔插？比如说从提供datasource的bundle，难道是从mysql数据库切换到oracle？我对这块的需求和背景不大了解，pufan同学能否简单的介绍一下你遇到的场景：在类似我图中的common bundle的功能模块中，需要实现热拔插。这可以帮助我理解，谢谢！
很常见的需求，举几个例子：
DB bundle：更换数据库连接池大小、更改连接参数
Log bundle：更改log级别
Cache bundle：停用或启用cache，甚至从本地cache无缝切换到远程cache。
等等
用osgi最大的思想转变就是活用service，要注意这个‘活’字，不但要面向接口设计，更要充分利用osgi框架的service依赖及查找特性进行whiteboard pattern设计，那时你就会发现开发速度达到甚至超越传统框架也并不是不无可能的了。
skydream 写道&&&& 再次更新，分成3个层次
老兄，service定义bundle在哪里，你这样做common bundle怎么能够热插拔？
对于热拔插的支持，我个人感觉在business bundle这个层面上比较有可能有需求，对于common bundle，似乎实际意义不大。
打个比方说，有一个短信网关之类的应用，在business层面上，增加，卸载或更新某个业务能力是可能的，比如对smpp sms模块的更新，增加一个rest方式的sms模块，这个热拔插请求是比较合理的。对于common层，我不大理解为什么需要热拔插？比如说从提供datasource的bundle，难道是从mysql数据库切换到oracle？我对这块的需求和背景不大了解，pufan同学能否简单的介绍一下你遇到的场景：在类似我图中的common bundle的功能模块中，需要实现热拔插。这可以帮助我理解，谢谢！
&&&& 再次更新，分成3个层次
老兄，service定义bundle在哪里，你这样做common bundle怎么能够热插拔？
to zhangdp_neu： 我想我应该明白了，你是因为通用的bundle太多，因此将其中一些类似的bundle合并成为一个bundle，依旧提供原有的service。
&&& 也就是说从1service / 1bundle& 修改为 n service / 1bundle ，从而减少bundle的物理数量，但还是保留原有的service封装。
&&& 这样理解是否正确？恩，有点这个意思。在你那个图上再加一个Bundle，不暴露服务，只是对外export工具类一类的。不好意思，下班了，跑了
zhangdp_neu 写道skydream 写道erbin 写道osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。
“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！
有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。
bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。
以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。
上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。
我坚持bundle最少的原则。
业务层面的基于Service的划分，这个层面实现了业务级的复用。
系统划分成模块后，如果此模块内部组件没有热插拔方面的特殊要求，那么整个模块就为一个bundle.
可以同时对外提供一个或多个服务。
如果此模块中某个组件（或功能点）有热插拔等特殊需求，此模块为一个主Bundle。
只定义出热插拔组件的一些接口。
热插拔需求的组件和相关类等划分出来，单独为一个bundle。
业务层面的类库划分，实现代码级别的复用。
将一些业务相关的公共类划分，只是定义抽象类，公共类一类，业务异常等。
&&& bundle最少的原则，我也有这个倾向，不过没有你这么强烈。可能我还没有在实际的开发中正式使用，感触不够深刻，呵呵。
&&& 我目前的想法倾向于将service按照是否带有business含义划分为两种类型：有business内容的serive，比如说取一个用户资料，执行一个客户请求；没有business内容的service，主要是指内部实现，比如获取数据库datasource，一些公共的工具类或者工具模块。
&&& 后者理论上也可以不单独出来而是以类库的方式分别打包在不同的带business内容的service所在的bundle里面，但是这样就有重复的问题。因此对于一些比较重要而又被很多bundle使用的service，即使它不带business内容，也没有热拔插的要求，我还是倾向于将这个service提取为单独的bundle。我的经历是这样，开始的时候，日志，数据库datasource等都是单独的bundle，对外提供服务，后来发现这样Bundle多的控制不住。后来，日志，datasource等都提取到一个bundle中，做成及系统级组件，都是对外提供服务（业务无关的服务），另外有一部分做不成服务的，直接对外export了。没有将所有其作为jar吧打在lib里。而是做为一起部署的一个bundle。
skydream 写道erbin 写道osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。
“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！
有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。
bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。
以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。
上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。
我坚持bundle最少的原则。
业务层面的基于Service的划分，这个层面实现了业务级的复用。
系统划分成模块后，如果此模块内部组件没有热插拔方面的特殊要求，那么整个模块就为一个bundle.
可以同时对外提供一个或多个服务。
如果此模块中某个组件（或功能点）有热插拔等特殊需求，此模块为一个主Bundle。
只定义出热插拔组件的一些接口。
热插拔需求的组件和相关类等划分出来，单独为一个bundle。
业务层面的类库划分，实现代码级别的复用。
将一些业务相关的公共类划分，只是定义抽象类，公共类一类，业务异常等。
&&& bundle最少的原则，我也有这个倾向，不过没有你这么强烈。可能我还没有在实际的开发中正式使用，感触不够深刻，呵呵。
&&& 我目前的想法倾向于将service按照是否带有business含义划分为两种类型：有business内容的serive，比如说取一个用户资料，执行一个客户请求；没有business内容的service，主要是指内部实现，比如获取数据库datasource，一些公共的工具类或者工具模块。
&&& 后者理论上也可以不单独出来而是以类库的方式分别打包在不同的带business内容的service所在的bundle里面，但是这样就有重复的问题。因此对于一些比较重要而又被很多bundle使用的service，即使它不带business内容，也没有热拔插的要求，我还是倾向于将这个service提取为单独的bundle。
erbin 写道osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。
“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！
有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。
bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。
以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。
上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。
我坚持bundle最少的原则。业务层面的基于Service的划分，这个层面实现了业务级的复用。系统划分成模块后，如果此模块内部组件没有热插拔方面的特殊要求，那么整个模块就为一个bundle.可以同时对外提供一个或多个服务。如果此模块中某个组件（或功能点）有热插拔等特殊需求，此模块为一个主Bundle。只定义出热插拔组件的一些接口。热插拔需求的组件和相关类等划分出来，单独为一个bundle。业务层面的类库划分，实现代码级别的复用。将一些业务相关的公共类划分，只是定义抽象类，公共类一类，业务异常等。
osgi是个好东西，但是它还是存在Bundle粒度粗细问题，比如我要建立一个分布式系统，数据源层，dao层，业务层
显示层，每层都会有好多的Bundle有时候要新建一个模块的话需要引入很多Bundle而且引入的Bundle还要引入其他的Bundle这样整体的结构依然是紧密耦合的，没有达到osgi原本的初衷。
所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦。
“所以我觉得osgi的关键还在Bundle的粒度问题，怎么划分才是合理的 才能高度解耦”-----这个我非常赞成！
有关这个粒度的问题，比较头疼的是如果太小bundle太多管理起来太痛苦了，而有些bundle的功能可能比较简单，比如一些工具类。对于这种我感觉不如直接嵌入到使用它的bundle里面，以lib包的形式存在（当然这个也会造成多个bundle之间重复的问题）。
bundle的划分应该是基于service来做，而且应该以功能模块的边界为划分原则：同一个功能模块内，如果不对本功能模块外暴露，就应该尽量隐藏在该bundle(先假设该功能模块只有一个bundle的情况)内部，比如我上面说的直接打包在bundle的jar中。
以erbin同学的例子，“数据源层，dao层，业务层”，其中数据源层应该是被几乎所有需要数据库访问的bundle使用，有必要做成bundle提供service来操作数据源，而在这个数据库的bundle内部，如何使用就应该屏蔽起来，比如说使用c3p0来做连接池，这个c3p0的jar包就没有必要暴露给外部了。"dao层，业务层"，如果不是被多bundle公用，就应该封装然后以service的形式供其他bundle调用。
上述的想法暂时还不成熟，我还没有实际使用，有点纸上谈兵的感觉。但是基本的出发点就是，bundle的粒度不能太细，数量不是越多越好。
javaonejcy 写道对应用过于复杂的技术就是无用的技术。osgi离成熟尙远。
这个不敢苟同，osgi已经足够成熟了，只是它设计的初衷不是针对企业开发，所以目前迁移到企业开发时遇到比较多的问题。至少在ide，app server基本是不二选择，怎么至少给出“无用”的评价。
成熟与否，不能看别人说的，还是要结合到自己的应用中。你希望OSGi提供哪些特性？他是否提供？是否满足你的要求？不可能有一个方案能满足你的100%需求的。
此外，还要看你个人、团队的驾驭能力，驾驭能力不够，就只能使用JSP等基础技术了。
OSGi不就是一个模块化的支持技术吗？如果你需要，且用得上，在目前也没有更好的技术的情况下，大可放心使用。毕竟，eclipse、spring等至少保证OSGi本身是基本完备的。剩下的问题，就只有自己发挥了
& 上一页 1
浏览: 384590 次
来自: 广州
感觉你们都很牛掰，我们做的一个运维平台也是用karaf的，用k ...
“自作聪明”的使用了读写锁，其实只使用ReentrantLoc ...
你这个代码是sublist后仍然一直持有这个sub的引用，一般 ...