项目知识 - 分布式soa架构理解

    下面是我结合实习经历总结相关的知识，只是个人理解，有错还请指点。

    一、在我大学期间写过很多小的demo，但是这些demo基本上是所有内容一个项目，然后把这个项目部署到tomcat中发布。类似下面这个图

    但是随着项目的访问量的增大一个tomcat所能承受的并发量大概就200来个，这个时候有2000个用户访问你的网站怎么办？可能会想到，我项目拷贝部署到10个tomcat下不就好了，但是这样带来很多问题：

        比如一，10个项目启起来，用户通过一个域名（nginx反向代理后面说）在10个项目间随机访问，A用户第一次等了请求的是tomcat1，记录了session，他登陆之后发出请求这次被tomcat2接收到了，可是tomcat2上没有A用户session，怎么办？我们得在10台tomcat之间做session复制这样效率肯定是很低的（我也不太了解session复制大佬给我讲的，我觉得这不是最重要的问题，因为也可以通过redis做一个session缓存让10个tomcat访问）。ps：想了想这个并发量的解决，不是分布式解决的，还得归结到集群的头上，但是分布式结构更加有利于我们合理搭建集群。

        比如二，互联网项目迭代是很快的，如果在一个项目里，我们包含了前台展示页面，以及后台cms，我们要更新前台的时候是不是得把整个项目停了，我后台内容管理系统cms是不是此时也不能用了？

        比如三，其实一个项目中不同功能的并发量并不是一样高的，比方前台展示服务肯定是无疑是并发访问量最大，而比如查询个人信息服务并发量其实是很少的。可我们项目是一个整体，没有办法按照需求单独给它们配置服务器。

        比如四，我们项目中提供了用户信息展示服务，但是此时公司另外一个项目也需要信息展示的功能，难道再去重新造*吗？我们直接通过协议调用我们之前写好的服务是不是很方便？可是在上面那种结构下我们的服务并没有暴露出来接口给外部。

   二、先结合上述问题一问题二，加上最近在公司所学到的分布式soa架构方面的只是我来讲讲，前两个问题如何解决。我们可以将一个项目按照系统进行划分，使得其一个项目由几个小的子系统来进行拆分。如下图：

        按照上面这种分布式结构，我么可以解决了系统之间独立部署升级之类的问题。但是中间还存在很多问题比如子系统还是有很多公用的业务逻辑不能公用，比如前台后台系统都有查询用户所有信息的功能，我们是不是可以抽出一个查询服务呢?。不能重复造*，所以我们还得拆，拆成下图结构才是真正的分布式soa（面向服务）架构

        可以变成上面这种结构，所有系统可以由我们写好的服务（每个服务单独运行在tomcat容器中）组合出来，图有点不恰当其实调用路由并没有这么复杂，我使用的是dubbo来进行远程的调用，会帮我们经行路由管理。dubbo使用后面帖子会写。