多年来对架构的认知

前言

      10多年工作经验，目前因为大专学历，半年找不到工作，才有空总结一下。

在脉脉等平台看到了很多文章，很多没用的，不提了。也有一些文章，只是看中某些具体的框架，好像会了及厉害了，我个人的理解 概念和经验很重要，那些东西只是选型。

      Java这行，出新东西的速度很快，但最终服务于业务，这没错，但这只是半句，还有半句是，要根据生产环境进行不断的调整。

其实，你的架构图在白板上画出来，反复的去揣摩各个点，不断的细化，解决了一个一个瓶颈之后，会发现这才是真正的经验，个人看法。

一、垂直框架

     这是最基本的形式了，典型的代表是SSH、SSM，基本的MVC结构，以JSP为页面的多一些，struts或者springMVC来接收请求，业务层service用spring处理已经是基本做法，spring从1.0开始，最核心的就是容器和Bean，省了很多事情。之后Dao，用hibernate或者mybaties比较多。

     至于中间是否还用了其他东西，看具体环境和需求了，比如缓存、消息等等。

     特点：

1. 搭建简单，主要的是4部分，页面，一般jsp和html，vue之类也可以做怎么布局了；web层，常用很多，springboot、springMVC等，特殊一点的是wicket类似于swing写法的wicket，但安全性很高，当然还有基于servlet的非开源，3.0以后，web.xml不用写了，说实话，有web.xml挺方便的。
2. 对分布式session的支持

        之所以考虑这点，是基于负载，有些网站是采用这种框架，外包的多一些，不支持分布式session，会在访问比较大的时候做负载麻烦，nginx一般策略是ip轮询和iphash。一般方式有两个：

       1）基于shiro，通过在缓存中保存session，可以实现session共享，wicket不行，至少7.0版本还不行，获得session的模式不同，真弄出来恐怕会比较麻烦。

       2）基于tomcat设置，tomcat好像是6.0开始支持的，通过一些设置，实现内存中一些东西在多个tomcat间复制，但springboot已经不需要依赖单独安装的tomcat了

       个人观点：shiro主要功能是管理权限，但能解决分布式session问题，即使用shiro，个人还是更倾向于使用单独安装的tomcat，tomcat支持很多，很多东西集中在代码里去处理，当发生区别的时候，代码多套，不如多个tomcat不同设置。

二、分布式框架（这里不包含微服务）

     分布式，我不看各种小编写的概念，根据工作中实际的体会，大体意思是，职能分散。具体情况中，更多的是按照业务操作划分的，一个操作是一个接口，同类的操作放在一个服务里面。当然，也有拆得细的，有点类似于微服务了。举个例子，比如下订单：请求进了controller以后，只有一个参数整理逻辑，然后调用订单服务的下订单接口，也许下订单接口中会判断是否是会员，调用会员服务去新建用户。

     好处：

      1）分布式服务刚开始更多的是职能分开，不同的职能使用次数是不一样的，负载权重在这方面可以更加灵活。

      2）增加一个职能，可能只需要修改某个服务，不需要全部重新部署了。

      3）职能服务分开，从产品到研发的分工也可以更细，有的产品和研发只负责零售、有的只负责订单，当然有的公司做不到。

     特点：

      1）  服务间多采用http，webservice，当然，也用过hession和thirft。

      2）大部分服务间走内网，有一部分需要暴露供外网调用。

三、微服务框架

     微服务，在一定程度上可以说是分布式服务的再细分，但也不是绝对的，微服务拆分的服务功能相对单一、独立，具有独立的缓存和DB资源，单一、独立的功能决定了这个服务不止可以给一个平台提供服务，类似于支付。举个例子：

比如快递，快递需要与第三方对接，原来的方式：放在订单服务一起，发完快递，单号保存在订单上，如果第一次快递失败，重新发，需要把新快递单号更新到订单上。微服务方式：快递作为单一服务，有独立的DB和缓存，对外提供下快递单、查询的接口，最终业务流程可能不变，基于业务流程也没发现好处。可以对比一下哪里不一样了：

1. 快递是可查的了，不论发多少次，有记录了
2. 如果合作方变更，不需要动订单服务，订单服务的重要性都知道的。
3. 快递可以给订单服务提供下单，那其他系统是否可以呢？只要注意了幂等原则，有什么不可以。

    微服务现在用rpc形式去做的比较多，hession、dubbo只支持Java，thrift可以跨语言，serviceMesh我还没用过，不太清楚。另外关于springcloud系列，feign的调用方式挺好的，我只是对于里面的一些变革有自己想法，关于减少配置文件，利用注解在代码里写，对于开发来讲有些东西方便了，写法上随便一些了。但真的方便了吗？好像是spring3.0以后支持的packageScan，那配置文件中写的bean，都会是一些比较特殊的，在代码和配置文件中哪个好找？虽然还支持写在配置文件中，但好多文章宣传这么写，也并没有举例说明好处，在我看来像是跟风，怎么用还是看实际情况。

四、聊聊架构

     在我的概念中，架构和框架不是同一个概念，能搭框架跟架构完全不是一码事。

     我考虑架构，会包含以下这些，顺序不是绝对的，没有备稿，只是随手写的随笔，可能会写少了。

　　从请求的方向：

     1.  页面资源，网站、移动站、crm、app等，

　　放在CDN的：

         1）静态资源，图片、css、js

         2）动态加载的页面，指的页面上有一部分内容是利用类似jquery的documentReady的事件去加载的，这样的页面，除了CDN回源的时候服务器会有流量，其他时候，只会访问接口。

          前后端分离的基于nodejs的响应式前端了解不太多，没处理过。

     2.分流

依赖的中间件是nginx、haproxy之类，一般是ip轮询或者iphash策略，一般情况下，没有分布式session问题，就可以用ip轮询了。做足球票抢票的时候，因为老框架用的wicket，所以用的iphash，4台服务器横向扩展，只有第一台压力是最大的，这个问题还不是临时能解决的。前后端分离以后，session的key记在前端了，这个问题也就解决了。

页面与服务间，http请求的分发可以使用nginx之类，有条件的再上lvs，设置dns服务商那里做ip轮询。现在微服务主要是rpc形式，rpc目前都有基于zookeeper的方案，但zookeeper是编程式的注册和卸载node，这点确实从15年以前就不喜欢。虽然是rpc，但都是tcp请求，以前就弄过haproxy+thrif的结构，现在nginx也支持tcp了。

    3.跨语言

     展示端也许是页面，也可能是基于window组件的外壳，比如.net、c++写的壳之类的，我用JavaFx写过一个小东西，也类似与外壳，http很容易就解决，因为都支持。

     但Rpc呢，工作中与.net的人有过接触，他们也能写Rpc，但目前看出了thrift，hession、dubbo都不支持其他语言。

          还一点需要注意，比如post，java的会把encode都做了，.net不处理就会出乱码，没经历过的，看着自己没问题的代码会不明所以。

    微服务方面，目前比较流行rpc，rpc在7层中属于第四层应用层，

     在代码上的特点是一个接口方法，不再去拼xml，json等数据格式。

     我用过的rpc有hession、thirft、dubbo，目前知道的就thirft是支持跨语言的。

     用dubbo的时候，没能接触生产环境，关于生产环境的dubbomonitor只是了解了一下，能确认的一点是dubbo目前只有java语言。

     thirft，通过官方提供的jar包和结构文件去生成代码，我记得有好几种。

    4.易于开发

    首先需要提供各种工具，和接入中间件client的基础framework，还要包含配置文件处理，定时任务等。

    提供代码生成器，其中，要将dao、service 独立分开，这是唯一一块对不同依赖影响最小的。dao需要扫数据库，生成mybaties或者hibernate代码。

    client、remote层，如果是传统分布式，这可以是个springMVC之类的web层了。如果是微服务，这里就是个要去服务中心注册的服务了，至于转http，还需要单独的gateway。

     基本的增删改查页面，这个页面应该是属于后台管理的，比如字典服务，生成页面后可以做增删改查的操作。这里也许需要shiro管理下权限

     所有结构基于maven parent module结构

     提供不同的测试环境

     提供 部署脚本 （玩分布式的时候，这种shell脚本写过很多次了，下载代码、编译、mv到tomcat下，重启tomcat）

               

           以上只是随笔写写，不在白板上去看，光凭想的话，很多东西还没写出来