多年来对架构的认知

前言

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

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

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

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

1、垂直框架

     这是最基本的形式了，典型的表明是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不一样设置。

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

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

     好处：

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

      2）增长一个职能，可能只须要修改某个服务，不须要所有从新部署了。

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

     特色：

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

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

3、微服务框架

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

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

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

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

4、聊聊架构

     在个人概念中，架构和框架不是同一个概念，能搭框架跟架构彻底不是一码事。

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

　　从请求的方向：

     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）

               

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