10多年工作经验，持续了好几个月，因为大专学历问题找不到工作。在脉脉等平台看到了很多文章，有些是不修地铁的说地铁不挤，不提了。也有一些光看中某些具体的框架，外包的这方面更严重一些，我个人的理解 概念很重要，那些东西只是选型。

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

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

   一、垂直框架

           这是比较基本的形式了，典型的代表是SSH或SSM之类，比较基本的MVC结构，以JSP为显示媒介的多一些，struts或者springMVC来接收请求，

    业务层service用spring处理已经是基本做法，spring从1.0开始，最核心的就是容器和Bean，省了很多事情。之后Dao，用hibernate或者mybaties比较多。

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

           特点：

                  1.搭建简单，springboot本身也可以快速搭建，dao层可以用jpa

                                   接触过wicket框架的，也可以试试类似于swing写法的wicket加html模式，wicket的特点安全性很高

                                  其他基于servlet的封装web框架，随着3.0，web.xml可以不写了，但说实话，有web.xml挺方便的，习惯吧。

                  2. 对分布式session的支持

                                  基于shiro，通过在缓存中设置session，可以实现请求分发下的session共享，wicket不行，至少7.0版本还不行，获得session的模式不同，真弄出来                   恐怕时间也比较长，不值当。

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

                                  支持分布式session的，基于反向代理，比如nginx或者haproxy之类，可以用ip轮序策略，不支持的只能iphash了，iphash的问题就是压力不均匀。

                                 个人观点：shiro不光针对分布式session还涉及到管理权限，分布式session主要针对在接收请求那层，即使用shiro，个人还是更倾向于使用单独安装的tomcat，tomcat支持很多，所有东西都针对在代码里去做，当有一些区别的时候，代码编程多套，不如多个tomcat不同设置。

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

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

             好处：

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

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

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

             特点：

                   服务间多采用http，webservice，当然，也用过hession和thirft。大部分服务间走内网，有一部分需要暴露的走外网。

   三、微服务框架

              微服务，在一定程度上可以说是分布式服务的再细分，但也不是绝对的定义，

              比如用户服务，传统分布式的时候，服务可能包含注册用户、查用户、修改资料，那么微服务呢，其实也差不多，

       也有不一样的。

               比如订单服务，订单相关的也许都做在一起，比如下单、计算折扣、快递等。

               那微服务的在订单的设计上就不一样了，计算折扣就可以是单独一个服务，这个服务的功能也不会只是计算折扣，这个服务也许就是一个不依赖

       其他资源的纯计算服务。

               另外，像快递，完全可以是单独的服务，以后也可以不光是订单来用，而且可以具备单独的缓存和DB，不需要占用订单的资源链接。

               大体的意思，传统的分布式是从职能拆分服务，微服务，是从功能，这个功能指的是单一功能，比如像快递、支付，可以不掺杂任何业务，调用端才和业务有耦合。

               微服务还一个特点就是rpc用的比较多。

    四、架构

              在我的概念中，架构和框架不是同一个概念，能搭框架跟架构不是一码事，这点在项目公司和外包公司体会会比较少一些。

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

　　　　从访问的方向：

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

　　　　　　放在CDN的：

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

                           2）动态加载的页面，很多页面有一部分是不会改变的，比如产品页，一般上架是需要严格审核的，名称、内容基本不会再变了，至于价格、库存，基本是              

                      异步加载的，这种页面放在cdn也不会有问题，访问这些页面时，只会产生接口请求，不会产生读页面的本地服务器流量，除了cdn回源的时候。

                            这里说明一下，对前后端分离后的基于nodejs的响应式前端了解不太多，没处理过                  

              2.请求分发

                      首先要考虑session问题，有状态的请求要考虑用iphash还是ip轮序，根据是否支持分布式session来看。

                      前后端分离以后，这个问题很少考虑了，vue等前端框架，在页面级别已经记录了一些东西，调用的接口基本是无状态的，尤其微服务形式，建立

              一个http访问端，比如springMVC搭的，只需要接入各个服务，提供http和rpc中间的处理。目前各rpc服务也有自己的分发方案。

              3.跨语言

                     展示端不一定是什么，比如.net、c++写的壳之类的，就需要跨语言的服务。

                     这里面基本最多的是http，没有不支持的，只是有些处理不一样。

                           比如post，java的会把encode都做了，.net的我见过几次，不处理就会出乱码，没经历过的，看着自己没问题的代码会不明所以。

                     因为很多工具也会有自己一定默认规则，比如postman。

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

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

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

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

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

                                           之前使用的方式也是启动时注册在zookeeper上，但当时来讲，我并不喜欢这种编程式的注册。

                                           后来，基于tcp请求，搭了haproxy+thirft的组合。放现在来讲，如果量不是很大，比如日活百万，这种方式完全可以了。

                                                  目前nginx也支持tcp请求转发了。

              4.易于开发

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

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

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

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

                      所有结构基于 maven parent module结构

                      提供不同的测试环境

                      提供 部署脚本 （玩分布式的时候，这种shell脚本写过很多次了）

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