这篇文章很赞， 收藏

http://hinchcliffe.org/archive/2009/03/17/16712.aspx

In the last year or so, after quite a lull, the software architecture business has gotten rather exciting again. We're finally seeing major new topics emerging into the early mainstream that are potential game-changers, while at the same time a few innovations that have been hovering in the margins of the industry are starting to break out in a big way.

The big changes: The hegemony of traditional 3 and 4-tier application models, heavyweight run-time platforms, and classical service-oriented architecture that has dominated for about a decade is now literally being torn asunder by a raft of new approaches for designing and architecting applications.

These might sound like incautious words but major changes are in the air and architects are reaching out for new solutions as they encounter novel new challenges in the field. As a consequence, these new advances either address increasingly well-understood shortcomings of existing approaches or add new capabilities that we haven't generally focused on before but are becoming increasingly important. A few examples of the latter include creating reusable platforms out of applications from the outset (the open API story) or cost-effectively creating architectures that can instantly support global distribution, hundreds of terabytes of data, and tens of millions of users. There are others that we'll explore throughout this post.

These innovations are hallmarks particularly of the largest systems being built today (which are running into unique challenges due to scale, performance, or feature set) though these software advances are also moving across the spectrum of software from everyday corporate systems and Internet applications to new mobile devices and beyond, such as the emerging space of social networking applications.

Mainstays of application architecture such as the relational database model, monolithic run-times, and even deterministic behavior are being challenged by non-relational systems, cloud computing, and new pull-based systems where consistency and even data integrity sometimes take a backseat to uptime and performance.

Let's also not forget about Web 2.0 approaches and design patterns which are becoming ever more established in online applications and enterprise architecture both. Social architectures, crowdsourcing, and open supply chains are becoming the norm in the latest software systems faster than expected in many cases. Unfortunately, as a result, the architectural expertise needed to effectively leverage these ideas is often far from abundant.

To try to get a handle on what's happening and to explore these emerging topics, I've been doing conference talks lately about the transformation of software architecture that we're beginning to see in so many quarters these days and generally finding consensus that the exciting days of architecture are back, if they ever left. Now it's up to us to begin the lengthy process of taking many of these ideas into our organizations and integrating them into our thought processes and architectural frameworks and bringing them to bear to solve problems and provide value. As one software architect came up and asked me recently, "How do I get my organization to understand what's happening out there?" This is an attempt at addressing that question.

Here's a list of the most important new areas that software architects should be conversant in and looking at in 2009:

10 Must-Know Topics for Software Architects in 2009

1. Cloud Computing. This one is easy to cite given the amount of attention we're seeing in the blogosphere and at conferences, never mind the (considerable) number of actual users of popular cloud services such as Amazon EC2. While the term doesn't have an exact definition, it covers the gamut of utility hosting to Platform-as-a-service (PaaS). I've covered cloud computing on ZDNet in detail before and broken down the vendor space recently as well. While the economics of cloud computing can be extremely compelling and there is undoubtedly a model that will fit your particular needs, cloud computing is also ground zero for the next generation of the famous OS platform wars. Walk carefully and prototype often to get early competency in an architectural advance that will almost certainly change a great deal about the software business in the near future.
2. Non-relational databases. Tony Bain over at Read/Write Web recently asked "Is The Relational Database Doomed?" While it's far too soon to declare the demise of the workhorse relational database that's the bedrock of so many application stacks, there a large number of promising alternatives emerging. Why get rid of the traditional relational database? Certain application designs can greatly benefit from the advantages of document or resource-centric storage approaches. Performance in particular can be much higher with non-relational databases; there are often surprisingly low ceilings to the scale of relational databases, even with clustering and grid computing. And then there is abstraction impedance, which not only can create a lot more overhead when programming but also hurts run-time performance by maintaining several different representations of the data at one time during a service request. Promising non-relational solutions include CouchDB, which I'm starting to see in more and more products, as well as Amazon SimpleDB, Drizzle (from the MySql folks), Mongo, and Scalaris. While many applications will continue to get along just fine with relational databases and object-relational mapping, this is the first time that mainstream database alternatives are readily available for those that are increasingly in need of them.
3. Next-generation distributed computing. An excellent story today in the New York Times about Hadoop provides a good backdrop on this subject: New distributed computing models are moving from the lab and becoming indispensable for providing otherwise difficult to harness computing power when connected to previously unthinkable quantities of data. While traditional request-response models that are the mainstay of network-oriented computing are important, so increasingly are effective ways to process the huge amount of data that are now common in modern software systems. Watch this video interview with Mark Risher and Jay Pujara at Yahoo that discusses how Hadoop "enables them to slice through billions of messages to isolate patterns and identify spammers. They can now create new queries and get results within minutes, for problems that took hours or were considered impossible with their previous approach." While Hadoop has considerable momentum, other similar offerings include the commercial GridGain and open source Disco and there are many others.
4. Web-Oriented Architecture (WOA). I've discussed Web-Oriented Architecture on this blog now for several years and my most complete write-up is here. In short, the premise is that RESTful architectures (and the architecture stack above and around it including data representation, security, integration, composition, and distribution) are a more natural, productive, and effective way to build increasingly open and federated network-based applications. The WOA debate has raged for a while now since it became a hot topic last year but the largest network on the world has cast its vote and WOA is the way that the Web is going by and large; WOA-based applications just align better to the way the network itself inherently works. In my opinion, it is a much better way to create service-oriented architecture for almost all requirements, resulting in more supple and resilient software that is less difficult and expensive to build and maintain. For enterprises considering the move to WOA, here is good overview I did a short while back about the issues and the evolution of SOA.
5. Mashups. David Linthicum wondered today in Infoworld where the mashups have gone, clarifying that he believed they had become integral to SOA and for delivering value in enterprise architecture. In reality, while mashups are extremely common in the consumer space, to the point that it's just an every day application development activity, the tools and concepts are just now ready for prime-time in business. I've previously called mashups one of the next major new application development models and that's just what's happened. Mashups were also prominent in my Enterprise Web 2.0 Predictions for 2009 (item #7). If you're not studying mashup techniques, Michael Ogrinz's Mashup Patterns is an excellent place to start studying how they impact software architecture .
6. Open Supply Chains via APIs. I find the term open APIs, which an increasing body of evidence shows are an extremely powerful model for cross-organization SOAs, to be confusing to the layperson so I've begun calling them "open supply chains." Opening up your business in a scalable, cost-effective manner as a platform for partners to build up on is one of the most powerful business models of the 21st century. However, there seems to be a large divide between native-Web DNA companies and traditional organizations in understanding how important this is (it's increasingly mandatory in order to compete online). All evidence so far points to this as one of the most important, though potentially difficult, things to get right in your architecture. Security, governance, scalability, and ease-of-consumption are all major subject areas and our enterprise architetures and SOAs must be ready for this business strategy as more and more organizations open up. Here's my recent "state of the union" on open APIs.
7. Dynamic Languages. Though dynamic languages have been popular on the Web since Javascript and Perl first arrived on the scene, it's only been recently that it's become acceptable to develop "real" software with them. .NET and Java are still extremely compelling (and common) platforms for writing and running application code but it's dynamic languages like Ruby, Python, PHP, and now Erlang that are getting all the attention these days. Why is this? As I explored in a detailed comparison a while back, a trade-off in run-time performance has generally been found to enable a large boost in productivity by virtue of what this lets dynamic languages accomplish. It also doesn't hurt that a lot of work has gone into newer dynamic languages to make them extremely Web-friendly, which is now one of the most common use cases for any programming language. Dynamic languages have architectural trade-offs of course, like any technology, though increasingly frameworks like Rails, CakePHP, and Grails are built on top of them which bring the latest best practices and design patterns, something that is not happening as frequently with older platforms. The tipping point has arrived however, and dynamic languages are beginning to take the center stage in a significant percentage of new projects. Software architects should be prepared.
8. Social computing. Developers and software architects are often uncomfortable with social computing aspect of software systems today but Reed's Law has unequivocally demonstrated that the value of social systems is generally much higher than non-social systems. Or you could just look at the many popular applications out there that are driven by their social behavior and derive their (often enormous) value from the participation it entails. Whether this is YouTube, Facebook, Twitter, or thousands of other social applications (business and consumer both), the lesson is clear: Social architecture is an important new layer in the application stack and it I've since made it two entire quadrants of my view of Web 2.0 in the enterprise as a consequence. A List Apart has a great introduction to The Elements of Social Architecture and I've identified some of the core patterns for this in my Enterprise 2.0 mnemonic, FLATNESSES. Fnding a high-value place for social computing in our enterprise architectures will be essential for modern software efforts.
9. Crowdsourcing and peer production architectures. Increasingly, the public network (the Web) has been used to enable potent open business models that are beginning to change the way we run our businesses and institutions. This started with open source software and has since moved to media and is now encroaching on a wide variety of industries. The models for doing this online require software architectures that can support this including architectural models for harnessing collective intelligence, moderating it, aggregating it, and protecting it and the users that provide it. As I wrote a couple of months ago in 50 Essential Strategies for Creating a Successful Web 2.0 Product, these architectures of participation create most of the value in the software systems that employ them. If you're not sure this is a software architecture issue, just look at Amazon's Mechanical Turk or CrowdSound, that latter which is a widget that allows even end-users to dynamically include crowdsourcing into their applications. You can also read John Tropea's new exploration of this topic for an application layer viewpoint.
10. New Application Models. The Semantic Web seems to be on the rise again and I've already covered Platform-as-a-service and mashups here, but in addition to these we are seeing entirely new application models cropping up in scale online. Whether these are Facebook applications, next-generation mobile apps (iPhone, Android, RIM, etc), OpenSocial or just the increasing prevalence of widgets and gadgets, the trend in the atomization of software (which was done still perhaps the best and most effectively so far in Unix) is reminding us that we still have new discoveries ahead of us. While these often seem trivial, aka applications as a feature, it's also increasingly clear that these are going to be here to stay and can provide considerable point value when they're designed correctly. Certainly for next-generation intranets and portals as well as the online "desktop", micro-applications which have to contend both with scale and with being useful and secure while embedded in other applications is increasingly on the radar. Know how they work, why they are so popular (there are tens upon tens of thousands of Facebook and OpenSocial applications alone) and learn how they can be used to provide real utility and every day value.

又是eclipse插件， 还是小日本写的，不过总比在web上方便了。

只是开发时要在本地起个shindig server， 所有数据都是本地模拟的，碰到容器自己扩展的API或不兼容的地方就麻烦了。不过既然是开源的 ，可以边玩边写办法。 

http://blog.opensocial.org/2009/03/introducing-opensocial-development.html

http://code.google.com/p/opensocial-development-environment/

With the OpenSocial Development Environment (OSDE), you no longer need an online OpenSocial container environment to build your applications. OSDE is a new Eclipse plugin that lets you develop either OpenSocial JavaScript (gadget) client applications or OpenSocial Java client applications using OpenSocial 0.8's REST/RPC protocols, entirely within the Eclipse development environment.

OSDE is the creation of Yoichiro Tanaka, an expert software developer and leading pioneer in OpenSocial development from Japan. Yoichiro has also published a book on OpenSocial development in Japan.

Installing the OSDE plugin onto Eclipse 3.4.1 (or later) takes only minutes, and you can be up and running with a fully self-contained OpenSocial development environment. OSDE provides a complete social network environment in a single plugin, along with the necessary tools to easily manage your environment's social data. Additionally, you won't need to create multiple accounts on a social network for testing your applications. This can come in handy if you happen to feel inspired to create a new OpenSocial app while on a plane!

Architectural Highlights

OSDE is able to provide a complete, standalone development environment because it bundles the same code running on many OpenSocial containers today into a single Eclipse plug-in: for serving gadgets and OpenSocial data, Apache Shindig is bundled along with a compact Java H2 database, allowing for social data persistence. OSDE also uses Hibernate for Java Object Relational mapping of the OpenSocial data entities: people, activities, and data. Plus, OSDE bundles the OpenSocial Java client library so its wizards can quickly generate runnable Java client applications that use OpenSocial's REST/RPC protocols.

Feature Highlights

OSDE also includes development features that greatly enhance OpenSocial development:

• OpenSocial project creator wizards for both JavaScript/gadget client apps, as well as Java client applications that use the REST/RPC protocols.
• A re-entrant gadget specification editor that enables efficient editing of OpenSocial gadget properties, views, locale settings, user preferences as well as gadget and spec/JavaScript source code.
• An OpenSocial console view that shows the console output of the local Shindig/H2 social engine, as well as tabbed views for directly managing the onboard People, Activities and AppData persisted social data.
  • OSDE users can use the social database console to edit their own custom social data (such as people, friend relationships, activities etc.), or they can simply load the sample social data that comes with Apache Shindig's 'Sample Container' application.

For more information on how to use OSDE, checkout the OSDE tutorial (which includes a screencast) and visit the OSDE homepage.

Posted by Chris Schalk, Google Developer Advocate

太喜欢Dion Hinchcliffe画的图了

引用

方兴东 的 【看图学2.0】Web 2.0应用解析，一目了然

如今，Web 2.0已经臭大街了，人人都厌倦了。不过，我还是很喜欢看Dion Hinchcliffe的博客，而且都是只看图片不看文字。因为，看他的图片比看他的文字更一目了然。仿佛回到了小学时候的看图说话了。转贴几张，与大家欣赏。感谢Dion Hinchcliffe。

不要流水帐了， 直接进入总结：

看到最搞的广告：数码港酒店的电梯里两个大液晶屏的广告竟然是广州热线的停车位游戏， 拿到第一名的可奖一吨汽油。

泛泛地介绍技术比深入到某个点要难。

如果可以在笔记本演示一些东西可以讲得更清楚， 可惜笔记本是借的，只装了个office。

广州邮件组的人很热情，认识了很多人。

咱们测试组开发的东西很牛B，让人刮目相看。

有空一定要认真看看Mapreduce的paper。

最大的希望：能开发出让自己觉得很有底气的产品。

好久没写了，所以先灌篇水， 引自 http://oplatform.org/archives/66 。

今年确实是中国的开放平台之年，虽然这个开放还是犹抱琵琶半遮面。

快过年了，咱们也来整体看看，评评奖。

最公正的开放平台——聚友（myspace中国）

从开放思想和对待开发者的角度来看，聚友是最为公正的真正从构建完善生态系统角度着手的平台，不过其用户量太少，即使好心也没太多的玩头。但是，这种精神我们是要大大的提倡和鼓励的！

最让人迷惑的开放平台——校内

校内的开放是让开发者真正兴奋起来的开放，那可是实实在在的大量用户啊。不过早期的协议争论和在维护开发者关系上的经验缺乏，让校内的开放魅力打折 了许多。我一直想问校内的一个问题，就是校内通过开放获得了什么好处没？这些好处与自己做相对比，哪个更大一些。在中国干长期的事情没有眼前的利益是干不 成的。期待平台也通过开放获得了切切实实的好处，这样，开放的事情才能长期搞下去。

千橡集团最近也做了个开心，这个开心要开不开的，这种思路会影响到校内未来的开发策略的走向吗？迷惑之。

最扯淡的开放平台——51

从用户数来说，51本是目前最值得期待的开放SNS平台，其开放平台的运营者也一直很得开发者的信任，其发言人对于开放平台的讨论文章也非常值得一看。不过到后面出尔反尔、杀鸡取卵，与开发者争眼前利益，说的比做的好多了，所以封之为最扯淡的开放平台，具体的事例可参见《扯淡的51开放平台》。

最“坏”的“开放”平台——开心网（kaixin001.com）

开心网凭借APP运营的方式，快速的占领了白领市场，整个架构也是采用开放的架构模式，不过一直不开放，近期也看不到开放的苗头。开发者一方面在模 仿开心的做法，另一方面也非常期待开心开放。从开放的事业的角度，开心还带了个坏头，让很多搞开放平台的人看到通过自己做和运营APP去获得短期利益的美 景，我们确实是只管抓眼前的老鼠的事情的。

最有“钱途”的开放平台——移动139社区

移动139社区（将来不一定叫这个名字）即将推出，据信也是采用开放的架构模式，被内部誉为移动梦网2.0。跟着它玩的能够成为SP2.0吗？小额 支付的便利性和前端收费的可能性（向用户收钱）是让开发者所期盼的。不过如何发展并留住用户是移动最需要解决的问题。这个平台不起来，跟它玩的人自然没饭 吃。

最憋屈的开放平台——一起网

我丝毫不怀疑谢文老师对于开放的思想境界，一起网也化了很大的努力去搭建开放平台的架构。不过无可奈何花落去，谢文老师的离开，让我看不到一起网的开放的未来。当然一起网还有很多很多问题，最让人憋屈的是一起本希望与开发者一起将一起做大，但是蛋和鸡的故事又在这里重演。

声音最小的开放平台——海内

海内的开放就这么开了，同王兴一样，不怎么说话。还好，很多开发者都是海内的用户，连其他开放平台也要在这上面开群组召集开发者，所以圈子里都是知道的，但是好像没多少开发者跟它玩，哎！

传说中目前最赚钱的开放平台——淘宝

在宣传资料里面看到有开发者在上面赚了几十万了，其他平台有人赚个几千块都跳到天上去了。能向商家收费，这个是个很爽的事情，不过不过出了宣传那 个，还有谁赚了很多钱吗？另外，就我所知，目前基本上给SNS开发的那群人基本上都不太跟淘宝玩，跟淘宝玩的人也基本不跟SNS玩，泾渭分明啊。马云说要 给优秀的开发者投很多很多钱，这个是不是会成为一个马大炮，俺也不晓得。“开放、协同、繁荣”是阿里集团的战略，目前来看，这个战略落地得还不够好，不是 所有的阿里人都有马总的境界的，下面的人还需教育教育再教育。

最快淡出视野的开放平台——搜狐blog

搜狐blog开得最早，不过走得个人门户的老路，采用的netvibes的标准，早期确实让人兴奋了一段时间，现在都没太多人兴奋了，慢慢的淡出了人们的视野，让我们谈起开放平台都不怎么想得起它了。

链条最长的开放平台——manyou（康盛油菜花相关）

其他开发者都是直接给平台开发应用然后给用户用，直面用户，manyou中间有个站长。你的站能运营多少个应用？你会去买应用吗？你会给康盛分钱吗？你会将你的用户和数据开放给康盛吗？链条虽然只增加了一个点，这工作难度可就是增长很多了。难啊！

最忽悠的“开放”平台——天际

灌水一篇，不过这篇文章确实很赞， 引自   http://oplatform.org/archives/66

最早加入Open Social联盟的中国网站是天际，在很多地方都看到它跟开放扯到一起，到现在还没看到它的开放，或者它就没想过开放，只是想借用开放，让它的名字出现下，好让我们还能看到它，别遗忘了。

在开放的事业中，有很多实干家，也有些忽悠的，需要听其言观其行。既然它喜欢忽悠，为了快遗忘的回忆，咱们再帮它忽悠下。

死得最快的开放平台——雅虎NCP

NCP是什么玩意，你听说过吗？是农产品的简称吗？匆匆出来，然后匆匆的消逝，不带走一片云彩。“农产品”生命如此的短暂，却不能如流星，闪耀一下，可怜的多少人的心血，就如此的没冒泡就消逝了。

好大喜功，不懂互联网的发展规律，忽视用户需求，老想一炮就把这江山打下，注定是要失败的。NCP再次证明了一条规律，这个互联网的世界里要扬名立万虽然没钱和人不行，但是只有钱和人也是扯淡的事情，特别是说不缺钱和人。

以上奖项请联系开放平台实验室，奖品：奖状一张！

PS：本次评选限于中国境内平台，不包括最有前途的facebook。另外，移动互联网那边还有些开放平台很值得跟的。还有些即将开放，比如新浪那边。

一问周围的人，竟然发现一大半都读过明朝的那些事儿，我真是落后分子，趁着看春晚无聊就在电脑上看书补课了，没想到一看就被吸引，一口气看了一大半。幽默、诙谐、悬疑，再加上时不时出来个著名人物，而且还能了解很多不为人知的历史，夫是太爽了。

后来看了作者介绍，一个海关的公务员，三年如一日，每天晚上花6个小时写作，这是什么支撑的他？应该是兴趣，有时兴趣远远比毅力或信念更重要。

忽然想起了国外的那些开源软件作者，白天写程序，晚上回到家继续开发自己喜欢的开源项目，没有外界的压力、没有功利心、甚至在第一个版本前没有任务反馈，只是因为喜欢，这是多么爽的事，又是多么高的境界。 Guido van Rossum用了9年时间在工作之余开发python， 这样的神人我只能仰慕。

这辈子我都不会达到这种境界，现在我只能想着把工作做好，混口饭吃，但这些神人是我的榜样和动力。

一朵微笑帮我们写的圈子帮助, 真好 

引用

一朵微笑 的 【原创教程】博客圈子管理帮助［图解］

　　前言：如果你是位博客圈子高手，这篇日志可以不用看了。

　　博客圈子，你我都是新手。这两天微笑仔细研究了一下，把我所了解的博客圈子管理方式打出来，与各位管理员共同学习。

　　一：登录圈子管理页面

　　打开博客圈子（本教程以一朵微笑圈子为例。一朵微笑圈子地址：http://q.163.com/asmile），点击右上角的“登录”按钮，弹出登录对话框，输入登录帐号和密码，点击“登录”按钮。如图１、

图１

　　登录以后，如果你是本圈子的管理员，你将会看到在页面的右上角有个“编辑我的圈子”按钮（如图２）。

图２

　　点击此按钮进入圈子管理页面（有时叫管理后台），其实它和普通浏览没多大区别。如果仔细看，你会发现页面上各个模块下有个管理按钮。如图３

图３

 

　　右上，也多了“排版”“设置”两个按钮。如图４。

图４

　　二：日志管理（即圈友推送过来的日志管理）

　　点击“日志”按钮，进入日志管理页面。如果你的圈子是从网易部落移过来的，可以重新对各分类修改管理。如果你的圈子还没添加过分类，那么就先添加几个分类吧。注：系统默认有两个分类，即“最新日志”和“推荐日志”。添加分类，虽然增加了管理员的工作量，但可以增加日志在圈子首页的显示篇数和延长停留时间，从而增加首页日志的点击浏览量。如果你是个懒人，就当我没说

　　１、添加分类

　　点击“管理分类”按钮，打开分类管理页面。点击“添加分类”，在分类名称下的框中填入各分类的名称。点击右侧的“确定”。如果不满意，还可以修改哦～～如图５

图５

　　２、显示分类模块

　　点击图４中的“排版”按钮，出现一个黄色的横条，上有“模块”和“版式”两个按钮，如图６所示。点击“模块”按钮，点击刚才新添加的分类模块，将其由灰色变为彩色，灰色方块变成小眼睛。如果模块为灰色，则其为隐藏状态，不能在圈子首页上显示。

图６

　　３、移动日志到分类

　　添加完分类，我们就去管理日志吧。把日志移到各个分类，是圈子日常管理的一个大项。

　　点击“管理分类”上边的“所有日志”（图５中的②所示），打开圈子里的所有日志列表。新推送过来的日志，都被设为“默认分类”，即“最新日志”类。点击日志标题后边分类下的小铅笔图标按钮。弹出一个小对话框，在对话框中选择相应的分类，点击“确定”。如图７

图７

　　４、推荐日志

　　图７中在小铅笔的右边，有一排小星星，在这里可以设置日志的级别。管理员通过日志级别的设置，来推荐和引导网友阅读。

　　从左到右，可以设置五个等级。鼠标左键点击星星即可。如果一篇日志被设为五个星，那么它自动成为被圈子推荐的日志，即移入“推荐日志”。

　　如果一篇日志被移动到某个类别，同时又被设为五星推荐，那么这篇文章一定时间内会在圈子的三个分类同时出现。即在“最新日志”、“推荐日志”和“某分类”同时出现。避免或利用这一现象，依各个圈子的管理方法而定。如图８

图８

　　三、圈友管理

　　１、审核圈友

　　点击“圈友”，进入圈友管理页面。点击“圈友审核”，打开待审核的圈友名单。“同意”和“拒绝”两个审核按钮，管理员看着办啦～～　如图９

图９

　　２、圈友推荐和设置圈子管理员

　　在推荐圈友之前，请先确认图６中的“推荐圈友”模块为显示状态，否则推荐了也不能在圈子首页显示。

　　点击图９中的“所有圈友”按钮，找到需要推荐或设为管理员的圈友。点击小铅笔图标，弹出个小对话框，如图１０。点击②所示的下拉菜单，将其设为本圈子“管理员”，或者不动，保留其“普通圈友”身份。点击“推荐圈友”前的小方框，将其显示为选中状态。点击“确定”按钮，设置完毕。

图１０

　　四：上传圈子形象秀

　　点击图９中的“关于我们”按钮，进入圈子信息个页面。

　　将“不显示形象”前的对钩去掉。点击“浏览”按钮，弹出对话框。在对话框中找到已经做好的圈子形象图片，将其选中，点击“打开”按钮（有的电脑上显示是“确定”或“好”等）。最后别忘了点击“提交”哦～～　如图１１。我上传的是ＧＩＦ小动画，但圈子“关于我们”页面它不动。呵呵～博客圈子还不完善。

图１１

　　圈子的板式和圈子信息设置，比较简单。我见有的圈子首页模块添加了自定义模块，做了背景音乐和图片等。目前网易博客圈子还不是很稳定，一朵微笑圈子还没有自定义模块的添加通道。等以后博客圈子功能更完善了，我再编写新博客圈子教程，我们再共同学习。谢谢！

通宵回来, 累.

经过了三个月的奋战, 网易的博客圈子终于正式上线了, 心里又充满欣慰。

尽管现在的功能还不是太完善， 但是我相信网易的圈子会越来越好的!

再发文章凑数. xiecc于2005年7月11日

在当今的MVC framework里，似乎Webwork2逐渐成为主流， Webwork2+SpringFramework的组合变得越来越流行。这似乎意味着Spring自带的MVC framework远比Webwork2差，所以大家纷纷用Webwork2来代替。确实，Spring的MVC framework不算是整个Spring的核心部件，但它的威力却超过了很多人的想象。很多人包括xiecc认为Spring的MVC framework是非常优秀的，甚至比Webwork2更优秀。
下面列举一下Spring的MVC framework在设计时做出的一些重要的决定，并将之和相关的MVC framework如Webwork2或struts进行对比：

一、 Spring的整个MVC配置是基于IOC容器的
与struts或webwork2相比，这是一个ms有点奇怪的决定，看一下Spring MVC的配置文件，最先看到的不是action或者form，而是一些有着特定名字的bean，Bean下面的配置是一些简单或有点复杂的属性。我们看到的是机器更容易的数据结构，而不是人更容易理解的元素。
但是这恰恰是Spring的MVC强大的根源！因为它的配置就是Spring的核心IOC容器的配置，这意味着所有IOC容器的威力都可以在这里展现，我们可以为所欲为地对Spring MVC进行扩展和增强，我们可以完成在其它MVC framwork中很多难以想象的任务。想扩展新的URL映射方式吗？要换一个themeResolver或LocalReolver的实现吗?想在页面中显示新类型的View（比如说RDF，呵呵，一个小秘密：xiecc是研究语义网的，虽然成天不务正业，不写论文，只写八卦）？甚至想直接在Controller里定义AOP吗？这些对Spring的MVC来说都是小菜一碟。
我没有仔细研究过Webwork2的扩展机制，我知道通过Webwork2的interceptor机制，可以进行很多的扩展，甚至有一个简单简单的IOC容器。但不管它有多强大，提供了多少扩展点。它的威力都很难和真正的IOC容器相比。而struts的plugin功能则是出名的滥，虽然它也提供了plugin机制。
Spring采用IOC配置的另一个原因是使Spring的MVC与Spring的IOC容器的整合变得非常的容易。Spring提供了与struts与webwork2的整合，但是这样整合都需要在进行间接的包装，感觉总不是很自然。而且还会导致一个概念多个配置，webwork2就需要在Spring里配置bean，再配置自己的xwork文件。想象一下吧，我们的bean直接就是一个controller,直接可以完成MVC的所有任务,这是多少爽的感觉。
Rod Johnson采用IOC容器来实现的另一个原因是这会减少好多开发工作量。看一下urlMapping吧，它提供的property本身就是一个HashMap，只有配置完成，我们的bean里的数据就自然存在了，哈哈，好爽吧。不用象struts那样解析XML，再把它的内容一项一项地读到HashMap里。
虽然这样的配置会有点怪异，但假如我们对Spring的IOC容器非常熟悉的话，会发现它非常的亲切，也非常的简单。
最后是一个简单的小秘密，Spring怎么知道某个bean的配置就是urlMapping？另一个bean的配置就是viewResolver？其实很简单，把所有的bean全部读到内存里，然后通过bean的名字或类型去找就行了。通过名字去找就是简单的getBean方法，通过类型去找则使用了BeanFactoryUtils.beansOfTypeIncludingAncestors的静态方法。

二、 Spring提供了明确的Model, View概念和相应的数据结构
在Spring里有一个有趣的数据类型叫做ModelAndView，它只是简单地把要显示的数据和显示的结果封装在一个类里。但是它却提供了明确的MVC概念，尤其是model概念的强化，使程序的逻辑变得更清晰了。
记得以前在Struts里写程序里的时候，为了显示数据经常自己把东西放到HttpSession或HttpServletRequest里（或set到form里，虽然不太有用），这造成了model概念的模糊，而且也导致了struts与JSP页面的紧耦合。假如我们要替换成Veloctiy,就得另外加一个plugin,因为在velocity里数据是不需要不放到request里的。
Webwork2里强调的是与Web framework解耦和它的command模式的简单性，因此在它的action里只有简单的get或set方法，假如返回数据，也只是简单地返回一个String。当然这样的实现有它的好处，但是它淡化了model和view的概念。Rod Johnson认为Webwork2里的Action同时包含了Action和Model的职责，这样一个类的职责太多，不是一个很好的设计。当然Jason Carreira不太认同这种观点，因为Action里的model对象完成可以delege给其它对象。但不管怎样，这种争论的根源在于Webwork2里淡化了model, view甚至web的概念。仁者见仁，智者见智，最后的结果还是看个人喜欢好吧。

三、 Spring的Controller是Singleton的，或者是线程不安全的
和Struts一样，Spring的Controller是Singleton的，这意味着每个request过来，系统都会用原有的instance去处理，这样导致了两个结果：我们不用每次创建Controller，减少了对象创建和垃圾收集的时间；由于只有一个Controller的instance，当多个线程调用它的时候，它里面的instance变量不是线程安全的。
这也是Webwork2吹嘘的地方，它的每个Action都是线程安全的。因为每过来一个request，它就创建一个Action对象。由于现代JDK垃圾收集功能的效率已经不成问题，所以这种创建完一个对象就扔掉的模式也得到了好多人的认可。Rod Johnson甚至以此为例证明J2EE提供的object pool功能是没多大价值的。
但是当人们在吹嘘线程安全怎么怎么重要的时候，我想请问有多少人在多少情况下需要考虑线程安全？Rod Johnson在分析EJB的时候也提出过其它问题，并不是没有了EJB的线程安全魔法，世界就会灭亡的，大多数情况下，我们根本不需要考虑线程安全的问题，也不考虑object pool。因为我们大多数情况下不需要保持instance状态。
至少我写了那么多的struts Action，写了那么多的Spring Controller，几乎没有碰到需要在instance变量保持状态的问题。当然也许是我写的代码不够多，Struts的设计者Craig R. McClanahan曾经说当时他设计struts时有两个条件不成熟：当时没有测试驱动开发的概念；当时JVM的垃圾收集性能太次。假如现在重新设计的话，他也会采用每个request生成一个新对象的设计方法，这样可以解决掉线程安全的问题了。

四、 Spring不象Webwork2或tapestry那样去隐藏Servlet相关的元素如HttpServletRequest或HttpServletResponse
这又是一个重要的设计决定。在Webwork2里我们没有HttpServletRequest或者HttpServletResponse，只有getter, setter或ActionContext里数据，这样的结果导致一个干净的Action，一个与Web完全无关的Action，一个可以在任何环境下独立运行的bean。那么Webwork2的这样一个基于Command模式的Action究竟给我们带来了什么?我想主要有两点：
1、 它使我们的Action可以非常容易地被测试。
2、 用户可以在Action里添加业务逻辑，并被其它类重用。
然而仔细跟Spring比较一下，我们就会发现这两点功能所带来的好处其实并不象我们想象的那么显著。Spring的Controller类也可以非常轻松被测试，看一下spring-mock下面的包吧，它提供的MockHttpServletRequest, MockHttpServletResponse还有其它一些类让测试Controller变得异常轻松。再看一下Action里的业务逻辑吧，Jason Carreira曾经说我们可以尽情地在Webwork2的Action里加业务逻辑，因为Action是不依赖于Web的。但是有多少人真正往Action里加业务逻辑的？大多数人都会业务逻辑delegate给另一个Service类或Manager类。因为我们很清楚，往Action里加业务逻辑会使整个体系的分层架构变得不清晰，不管怎样，Web层就是Web层，业务层就是业务层，两者的逻辑混在一起总会带来问题的。而且往Action里加业务逻辑会使用这个Action类变得庞大，Webwork2的Action是每个request都创建实例的，尽管带来的性能影响不太大，但并不表示每次都要把业务逻辑再new出来，业务逻辑在大多数的情况下应该是单例的。
不把request和response展现给用户当然还会带来功能上的损失，也许一般的场合，用用webwork2提供的接口已经足够了，但有时我们必须要知道request和response才能发挥出更大的威力。比如我以前的一个项目里有一个通过递归动态生成的树状结构的页面，在jsp页面上显示递归是痛苦或不可能的，因此我用response直接write出页面，这在spring里很easy，但在webwork里可能比较难了（偶不敢肯定，偶研究得不够深，也许高手是有办法的）。

五、 Spring提供了不错但不够充分的interceptor机制
回头看一下struts，它在架构里甚至没有给我们提供hook point的机会，我们没有任何机会加入自己的interceptor。我们只能通过重载struts的RequestProcessor类来进行一点有限的扩展。
到了Webwork2，似乎interceptor一下子成了整个Framework的核心，除了Action的核心部件，其它所有的东西都是interceptor。它的超强的interceptor功能使们扩展整个架构变得非常方便。有人称这种interceptor为AOP，Jason Carreira则自豪地宣称这个叫做pragamtic AOP。我不认同这是AOP，它只是简单的interceptor机制。但不管如何，它的interceptor确实有强大的功能。
Spring也提供了它的interceptor机制，它的HandlerInterceptor三个interceptor方法：peHandle, postHandle, afterCompletion。分别对应Controller执行前，Controller执行后和page render之后。虽然大多数情况下已经够用，但是从功能上来说显然它没有Webwork2强大。从AOP的角度来看，它没有提供around interceptor，而只有before与after interceptor。这意味着我们无法在interceptor前后保持状态，最简单的情况假如我们要计算一个Controller的执行时间，我们必须在执行完before后把begintime这个状态保持住，再在after里把它调出来，但是显然这个状态保持会是个问题，我们不能把它放到instance变量里，因为interceptor不是线程安全的。也许通过ThreadLocal可以解决这个问题，但是如此简单的功能要用到这样的方法来处理，显然这个Interceptor本身设计上还是有点问题的。
六、 Spring提供了MultiActionController，使它可以在一个类里包含多个Action
这个设计和struts的DispatchAction有点类似，只不过提供了更灵活的机制。当我们的项目变大的时候，把功能类似的方法放到同一个Action里完全值得的！Webwork2缺少这样的机制。假如看一下Spring的源代码，会发现其实实现MultiActionController的工作量相当的少，只不过是用反射机制把解析出来的方法名执行一下就完事了。其实Webwork2也完全可以提供这样的机制。虽然从设计上来说确实不是很优雅，但是它确实很有用。

七、 Spring提供了更多的选择方式
看看Spring里提供的Controller吧，它提供了好多不同的Controller类。要生成Wizard吗？要专门用于提交form的Controller吗?要执多个方法的类吗?Spring提供了丰富的子类来扩展这些选择。当然我们还可以很轻松地自己扩展这些功能。
再看看Spring的ViewResolver吧， 它提供了无数不同类型的ViewResolver。更重要的是我们自定义我们的页面映射方式。看看strtus，看看webwork2，都会存在页面与forward name的一层间接转换，我们必须在配置文件里配置好某个字符串（典型的是success）对应的是那个页面。但是Spring里我们有了更大的自由度，我们可以采用webwork2的策略，也可以采用更简单的策略，如将JSP文件名去掉扩展名的映射方法。也许有人认为这种映射方式很幼稚，但是我觉得它是非常有用的方式，即使在大项目里。
还有新的扩展吗？看看Spring Web Flow吧，它是SpringFramework的子项目。它为一长串的基于页面流的Wizard页面提供了可配置的实现方式。在Spring 1.3里，它将是SpringFramework的一部分。

八、 Spring的tag
尽管Spring的tag数量上少得可怜，但它却是精心设计的。它的目标很简单：让美工可以轻松地编辑页面。因为在Spring的页面里Text仍然是Text，checkbox仍然是CheckBox，而不象在struts或webwork2中的Tag。它只是用Springbind对输入内容进行了一下包装。所以尽管页面显示代码上会比Webwork2多，但这绝对是有价值的。

在接下来的几章里，我会分析一下Spring是如何让我们的Web应用不需要知道ApplicationContext就能够访问IOC容器的，然后会对Spring的设计和执行过程进行简单的源码分析，然后给出几个扩展Spring MVC的方法。

开会也许是我这这辈子最痛恨的事情之一, 尤其是想起昔日有一阵子的马拉松式(连开八小时的会议, 每周N次)会议更是心有余悸。
所以当初听说每天开scrum会议的时候心里也暗怕, 没想到一个多月下来,大家都爱上了开会，每天大家都嚷嚷着去开会，
想想真是有意思。
为什么大家爱开会？
1、工作太紧张的时候，开会可以放松一下。
2、大家坐下来交流一下，瞎乱聊一通挺好玩。有时大家互相启发一下也挺有收获。
3、没有领导，每个人都感觉很轻松，大家都平等的感觉，没有任何压力。
4、时间短，一般15分钟解决， 长一点20分钟， 大家都不会觉得烦。

最近写程序狂累， 先找一篇以前写的blog蒙混一下啦，反正最近刚要用Acegi。

xiecc于2005-11-19

偶对Acegi Security System景仰已久，它利用了Spring提供的IOC和AOP的机制，实现了一个安全架构，让我们的业务逻辑和安全检查逻辑完全解耦，所有的安全逻辑只要通过Spring的标准配置文件的定义就可实现了。不过说得简单，真的每次拿起Acegi Security System来看的时候，感觉就象云里雾里，如果不仔细看它的文档，再深入研究的话，根本就看不出头绪。某种程度上来说，学习Acegi Security System似乎比学习Spring还要难。

最近偶沉下心来，花了好多时间，看了文档和主要的源代码，终于摸出了点头绪。为什么Acegi Security System会这么难？我觉得原因有以下几个：

一、Acegi Security System的配置文件是用的是Spring的标准配置。某种程度上，它的配置是针对Acegi的设计和实现都很了解的人，而不是针对最终用户的。配置文件里那么多的类，那么复杂的对象关联，如果没有对Acegi的设计有深入了解，只能看得云里雾里。也许我们能在Acegi Security上包一层，定义自己的配置文件来简化Acegi Security。但是仔细想想，Acegi Security的设计是有道理的，Security本来就不是一件简单的事，我们不能指望一个新手来完成所有Security的配置。而利用Spring的配置文件却能达到最大的灵活性，利用Spring的IOC机制，所有的配置都可以提供我们的自定义的实现。一旦当我们对Acegi有了深入了解之后，所有的这些配置就会变得很自然了。

二、Acegi的文档相当的好，它将Acegi的内部实现、类之间的关联，实现的目标进行了很深入的分析。但是却忽略了一点，它的整个文档是从设计出发，而不是从需求出发的，整个文档似乎更关注于Acegi Security是怎么设计的，而不是怎么用的。当然我承认如果要深入了解Acegi，我们必须要知道它的设计和实现，但是对于一个新手来说，假如我们能马上知道Acegi的安全认证执行流程是怎么样的，再通过个认证流程展开说明authentication和authorization所涉及到的东西岂不更好？

今天先写到这里啦，过两天再写一下Acegi Security的认证流程吧，还是蛮好玩的，虽然写起来可能会有点累。

最近老被人叫做牛人, 心里好惭愧（seriously）。

其实公司里有好多牛人， 昨天听完wy的讲座，感觉自己很渺小。鸟对技术的敏锐性和知识面是偶无法比拟的。开发博客的那几个主力每个都是独挡一面的高手。还有象猪头那样精力过剩的程序高手，真是后生可畏啊。

不过也觉得很高兴，公司有这么牛人，何愁发展不起来？

我不是搞搜索专业的，当时毕设做了个简单的分词算法，就放到blog上。没想还有挺多人感兴趣的，记得那天点击量忽然达到2000（当时我的日点击量也就200），很多做搜索的人找我，说思路不错。也许我这辈子再也不搞搜索了，就把这篇文章放这留个纪念吧。

xiecc于2006年2月11日

最近折腾毕业论文，搞得人没心情写blog了。于是觉得不如把毕业论文里的东西贴出来当blog算了。这里主要介绍了我自己的中文分词算法，我觉得它比现在开源代码比较多的中文匹配法要好多了。这里的内容没有任何背景知识啥的，毕竟论文里的背景知道我也是从网上粘贴的，呵呵！因此这篇文章的内容可能适合做搜索引擎的人。如果要了解中文分词算法在搜索引擎中的重要性，或者最大匹配法的思想与过程，请去网上搜吧，资料还是蛮多的。

1.1.1 最大匹配法分词的缺陷

尽管最大匹配法分词是常用的解决的方案，但是无疑它存在很多明显的缺陷，这些缺陷也限制了最大匹配法在大型搜索系统中的使用频率。最大匹配法的问题有以下几点：

一、长度限制

由于最大匹配法必须首先设定一个匹配词长的初始值，这个长度限制是最大匹配法在效率与词长之间的一种妥协。我们来看一下以下两种情况：

（1）词长过短，长词就会被切错。例如当词长被设成5时，也就意味着它只能分出长度为5以下词，例如当这个词为“中华人民共和国”长度为7的词时，我们只能取出其中的5个字去词库里匹配，例如“中华人民共”，显然词库里是不可能有这样的词存在的。因此我们无法下确的划分出“中华人民共和国”这样的词长大于5的词。

（2）词长过长，效率就比较低。也许有人会认为既然5个字无法满足我们的分词要求，何不将词长加大，例如加到10或者100，毕竟这个世界超过100个字长的词还是很少见的，我们的词长问题不就解决了？然而当词长过长时，我们却要付出另一方面的代价：效率。效率是分词算法、甚至是整个算法理论体系的关键，毕竟算法书里所有的高深的查询或排序算法都是从效率出发的，否则任何笨办法都可以解决分词效率低的问题。设想到我们把字长设成100个词时，我们必须将词从100开始一直往下匹配直到找到要查的字为止，而我们大多数词的字长却只有两三个字，这意味着前97次的匹配算法是徒劳的。

因此我们必须要在词长与效率之间进行妥协，既要求分词尽量准确，又要求我们的词长不能太长。尽管我们可能找到这样一个比较优化的字长值使两者都达到比较满足的状态，但是毕竟不管我们怎么设定，总会有些太长词分出来，或者带来效率问题。

二、效率低

效率低是最大匹配法分词必然会来的问题。即使我们可以将字长设成相当短，例如5（注意，我们不能再缩短字长了，毕竟字长为5以上的词太多了，我们不能牺牲分词的准确），然而当我们的大数词长为2时，至少有3次的匹配算法是浪费掉的。回想一下算法书里提到的最简单的字符匹配与KMP算法之间天差地别的效率，我们知道通过某种方法，这些浪费的掉的匹配时间是可以补回来的。

三、掩盖分词歧义

中文是如此复杂的语言，它的表达方式如此之多，语法文法如此精妙，机械的电脑是很难理解这么复杂的语言，因此它必然会带来歧意性，以下是两个简单的例子：

A.“有意见分歧” （正向最大匹配和逆向最大匹配结果不同）
有意/ 见/ 分歧/

有/ 意见/ 分歧/
B.“结合成分子时” （正向最大匹配和逆向最大匹配结果相同）
结合/ 成分/ 子时/由于词的歧义性使我们在使用最大匹配法分词会产生错误的结果，而且使用正向分词与逆向分词往往会产生截然不同的结果。尽管使用回溯法或计算计算词的使用频率，可以使出现歧义的可能性减少，但是我们知道，这样的结果是不可避免的，因为中文的变化实在太多了。

四、最大匹配的并不一定是想要的分词方式

最大匹配法基于的理念是找到最大的匹配词，但有的时候除了最大匹配词外，我们也可能只需要这个词的一部分。例如“感冒解毒胶囊”是一个完整的词，按照最大匹配法我们无法对它进行拆分了，这样我们输入“感冒”的时候就根本搜不到我们需要的词。这是我们需要的吗？做为生产这种药的厂商，它肯定希望用户输入“感冒”甚至“解毒”，我们都能查到对应的内容。

1.2 设计自己的中文分词算法

1.2.1 设计目标

基于对分词算法的理解和对最大匹配法分词的分析，我们知道我们必须提出不同的解决方案，使分词算法的效率、分词的长度限制甚至歧义处理上得到提高。因此我们提出了如下的设计目标：

一、 高效

中文分词算法必须要高效，毕竟效率对于搜索引擎的重要性是不言而喻的。而且我们面对的是海量的数据，而不是一篇几百字或几千字的文章，效率的差别的影响可能会使最后运行效率差几个小时甚至几天。因此我希望我们设计的算法一定要比最大匹配法高，毕竟我们已经常看到最大匹配法的很多次匹配都是浪费在无用功上了，肯定有办法把这些浪费的时间节省回来。

二、无长度限制

最大匹配法的长度限制真是很讨厌的事，我们很难找到词长与效率的之间的平衡。为什么我们需要长度的限制？为什么我们不能设计出任何词长的词（只要词库中存在）都可以分出来？

三、歧义包容

我们相信长度限制的问题总是可以解决的，因为虽然长度限制这个问题很难，但是它是有规律可循的，它是严谨的科学。但是当我们碰到中文歧义时，我知道不管我们怎么努力，它仍然是不可能彻底解决的。因为中文实在太博大精深了，即使有极强的人工智能和机器学习功能，这样的错误仍然是难以避免。既然无法避免？我们为什么不换一个角度去考虑？我们为什么不可以将出现歧义的各种可能性都包含进去，作为分词的参考。例如上述的“有意见分歧”的两种分词方法：

有意/ 见/ 分歧/

有/ 意见/ 分歧/

为什么我们不能把这样两种结果都拿来分词呢？毕竟分词的目的是为了搜索，而不是为了教小孩读出。如果把两种分词的可能性都告诉搜索引擎，搜索引擎会很高兴的，因为这下不管是“有意”还是“意见”，它都可以搜到了。这就是我提出来另一个目标：歧义包容。

1.2.2 算法的突破口—词库

虽然我们的目标已经确定下来了，但是要想出一个更好的算法却是非常难的事。毕竟算法需要的是灵感与突发奇想，这与系统的架构设计和面向对象的设计与编者编码刚好是相反的，象设计模式或重构这样的东西我们需要的实践、总结、再实践。而算法需要的却是当我们在山重水复疑无路的时候会换个角度思考。

但是分词算法的突破口在哪里呢？我们必须要有一个词库，我们必须将全文中的词与词库去匹配，这一切都是不可避免的。

真正要改善是就是我们的匹配过程，我们要减少匹配过程中的浪费，我们要解决匹配中的词长限制。但是我们有什么办法呢？每次的匹配我们必须要去词库中查找一次。怎么改善这样的做法？

我们总是把优化的思路定格在更好的匹配算法，更好地处理词条和全文。但是真正束缚我们的却是词库！是基于关系数据库的词库，我们需要的对词库的改造，我们要让我们的词库更适合用于匹配与分词！

这是几十年来关系数据库带给我们的思维：我们查找的词是数据库的某条记录，通过表格与关系代数，我们总能找到这个词。但是正是关系数据库的这种思维束缚着我们，关系数据库让我们的数据结构及关联表达得清楚又简单，并使某些查询的效率变得很高。但是这不适用于中文分词，有的时候退到几十年前流行的数据库模型也许更适合。这就是层次数据库。

我们要做的是将关系数据库的词按字打散，并存放到层次数据库中。以下就是一个示例：

红色的字表示树上面的字串是可以单独组成一个词的，例如“感冒”它本身是词库里可以找到的词，所有红色的表示的是终止符。而黄色则表示树上面的字串是无法单独成词的，例如“感冒解”是不存在的词。

真的很奇妙，词库经过这样的改装后，所有的匹配的思维都变掉了。任何一个句子都会打散成单字去与树状结构的单字去匹配，词的长度变成了树的高度，每一次的匹配变成了树的遍历，而这种遍历的效率竟然都是线性的！

1.2.3 中文分词算法设计

有了以上的中文词库后，我们分词算法设计就水到渠成的。首先我们来看一下分词的步骤：

（1）首先将要分的全文按标点符号打散成一个一个的句子。这算是预处理的一个步骤，目的是让我们处理的句子短，效率更高。毕竟中间有标点符号的词是不存在的。（注：真正实现时我们是基于lucene的SimpleAnalyzer来做的，因为SimpleAnalyzer本身就是为了将全文打散成句子，因此我们没必要耗费体力去实现这一步）。

（2）我们开始将要处理的句子在树状结构中遍历，如果找到匹配的就继续，如果遇到红色的终止符，我们就发现这个词是一个完整的词了，这样我们就可以把这个词作为一个一个分词了。

（3）从分词后的下一字开始继续做步骤2这样的遍历，如此循环往复就将词分完了。

可以看到，我们字符匹配效率几乎是线性的！我们所要做的只是取出每一个字去树上找到相应的匹配，每次的匹配代价都是O(1)（如果词库用Hash表的话），这样匹配下来的时间复杂度就是字符串本身的长度！对于一个长度为n的字符串来说，它的分词复杂度是O(n)。而最大匹配的平均复杂度是O(n²)。

当然我们这里没有考虑歧义包容与分支处理等情况，但即使加上这些我们复杂度仍然是有限的。

1.2.4 中文分词算法的实现细节

一、建立词库

有了改装词库的基本思想后，建立词库的步骤变得很简单，但是仍然会有好多的细节需要注意。

首先是词库的保存格式。现在最常用的保存数据的方式当然是关系数据库，其次是文件系统中的二进制文件。显然关系数据库对于我们并不适用，而自定义的二进制文件则实现起来比较困难，而且读写的效率也会有问题。因为我们想到了最简单的方法是利用java的serialization的功能，把整个内存中的树状结构直接序列化成磁盘的文本文件是最方便的！而且读写的效率也会相当的高。

第二个问题是树的父子节点的导航。我们的树并不是一颗二叉树，父亲的子节点会有好多！尤其是第一层，我们会把词库中所有的首字都取出来作为根节点的子节点，这意味着如果首字有4000个的话，根节点就有4000个儿子。当然随着树层数的增多，节点的儿子数也会减少，毕竟以“感冒”开头的词在整个词库也只有四十多个，而以“感冒清”开头的词则只有两三个了。这意味着如果设计得不合理，我们树的匹配遍历过程并不完全是线性的。最坏的查找算法是O(N)（N代表儿子数）。当然如果我们建词库时将儿子有序排列，再按照二分查找的方法，则我们的复杂度会减到O(lgN)，这样的复杂度已经可以接受了。但是还有更简单又更快的存储方式，为什么不使用呢？那就是HashMap，毕竟在HashMap里查找东西时它的效率几乎是线性的，而且实现起来要比二分查询简单得多。当然用HashMap要付出存储空间变大的代价，但这样的代价来换取速度与简单性也是的。

第三个问题是找到有终结符的字后，我们必须要将它建成一个完整的词。这时我们必须能从字个往上回溯，直到找到根结点。因此我们在每个节点里都保存了父节点的指针。

有了以上的设计思想，我们就动手建立了我们的词库，词库的来源是中医药数据库的词汇表，因为我们应用一直是围绕中医药的。我们找到了两个最重要的表，这两个表几乎包含了中医药的全部词库：

一体化语言系统词库 92112个词

疾病大全、症状、证候 20879个词

最后生成的词库是java serialization的一个文件，文件的大小是16M 。当然这跟我们采用HashMap存放父子关联有关，也跟java的对象所占空间有关，虽然将词库按这种方式存放实际上也对词库进行了压缩（以“感”开头的字有数十个，关系数据库里就要保存数十个，但我们在词库只保存了一个“感”）。但文件仍然偏大，因此用oracle将这两个表导出后生成的文件大小是4M。不过这个大小仍然是可以接受的，毕竟效率才是关键。

二、 分词查询

虽然刚才对分词算法进行了描述，但实际上实现的时候我们还会碰到很多问题。

1、分支处理。

这是分词算法时歧义包容所必然碰到的问题。为了歧义包容，我们采用了与最大分词法完全不同的理念，我们的理念是将词库中存在词全部收入囊中！而且会发生重叠。例如“感冒解毒胶囊”，由于词库里存在“感冒”、“解毒”和“感冒解毒胶囊”这三个词，因此在分词的时候，我们会分别分出这三个词，这样用户无论输入“感冒”、“解毒”或“感冒解毒胶囊”搜索引擎都会找到相应的结果。

因此当遇到分支时，我们会分解成两条路线！例如当我们匹配到“感冒”的“冒”时，我们会发现一个终止符，代表“感冒”是一个完整的字，将它收录到分词中。接下来我们会分成两支，一支是继续往下走，匹配树的下一层，因为“冒”不是树的叶子，往下走可能会碰到更大的匹配词，例如“感冒解毒胶囊”。而另一支则从根开始，直接用“解”去匹配树的第一层节点，最后发现了“解毒”也是其中的一个词。

2、动态规划法

分支虽然使我们可以消除很多的歧义，但是显然它会带来副作用：导致分词的复杂度变大。如果一个句子很长时，分词的变化也许会呈指数级的增长，从一开始的两个分支变成四个、八个甚至更多。我们会发现很多句子虽然会有很多分支，但是这些分支又经常会汇聚到一个点，变成一个分支。例如：“感冒解毒胶囊可以治感冒”，我们在分词的时候可能会出现“感冒”，“解毒”，“感冒解毒”，“感冒解毒胶囊”等多个分支，但是当我们到达“囊”这个点的时候，所有的分支又会汇集到一起，因为大家接下来要处理的都是“可以治感冒”这个字符串。如果有办法让我们在汇聚以后只处理一个分支，那么算法的时间复杂度就不会象原来想象的那么坏。

而这刚好是动态规划法发挥威力的时候，动态规划要解决的问题是Overlapping sub-problem。它的处理方法就是将所有的子问题记录在公有的变量里（这里指的是类变量，它相对于某个method来说是公有变量，而不是真的全局变量）。当我遇到的子问题已经被处理过一次了，就直接跳过。这样节约的结果可以使算法复杂度得到质的改变，当然由于中文的变化多端，我们无法精确估计使用动态规划法后算法复杂度得到了多大的提高。

实际上的动态规划法的实现起来比说起来反而简单，我们只是简单地放了一个HashSet来存放已经分词过的位置：

然后判断的函数也相当的简单：

最后在分词的递归函数中加入这一句判断：

当这个位置已经被处理过了就直接返回了。

3、词库预load

在使用基于词库的方法时，我们必须要面临的一个问题是：必要将词库读到内存中，而这通常会耗费很长的时间，幸运的是这样的工作我们只需要做一次，当我们将词库load进来以后，所有的工作都会在内存中进行，分词的速度会得到极速提升。我们选择的词库预load时机是我们第一次进行分词时，这相当于lazy load，只有用到的时候我们才去初始化。

讲完算法，我们来看看分词部分的实现代码，实际上这部分的内容实现起来远比想中简单。在处理的过程中，我们对给每个句子（实际是lucene里用SimpleAnalyzer分词后的一个个Token）都新建一个ChineseSplitter，这是更加面向对象的做法，使我们处理起来更加方便简洁，因为我们会发现如果用一个Singleton的ChineseSplitter时，它的变量无法共享会导致整个Splitter里的递归方法跟上一堆的参数，容易出错，而且无法调试。代码如下：

代码简单明了，只是做了词库预load的工作后就将实际的分词工作交给了ChineseSplitter。

ChineseSplitter的核心功能实际上将句子中词典中能找到的词放到一个队列中，这中队列里提供了分词以后的所有词的信息：

下面是分词的核心算法：

它是一个递归的过程，初始时我们调用的参数里pos为0，这样它就会一级一级递归下去并将所有可能的分词放入到tokenQueue里。

1.2.5 中文分词的实验结果

1、实验1——短文分词

在第一个实验中我们选了一篇2000字的文章（是关于中医药的专业论文）。然后用三种Analyzer对它进行处理，以下是实验结果：

我们没有找到最大匹配法分词可用的开源代码，因此只能用SimpleAnalyzer和StandardAnalyzer与之比较。这两种算法事实上是根本没有去查词库的，因此也不会按任何语义去分词，SimpleAnalyzer只是简单地将文章按标点符号隔开成句子，而StandardAnalyzer则只是简单地将文章的中文字分成一个一个的单字。结果确实让人惊讶，当词库preload以后，我们的分词速度竟然远超不需要查任何词库的StandardAnalyzer算法！

2、实验2——建索引

这是将分词算法应用到我们的索引系统后的效果比较，我们的数据源是来自中医药数据库的几十张表，一共有九十万条记录：

由于建索引时数据库的查询操作会耗费很多的时间，因此两者的差别不是太明显，但结果至少说明了我们的分词效率确实是很高。