java技术--单体应用，分布式，微服务，集群

1.单体应用程序：

 （1）把所有的功能集中在同一系统中实现，应用程序的全部功能被一起打包作为单个单元或应用程序
 （2）这个单元可以是JAR、WAR、EAR,或其他一些归档格式，运行在同一个 tomcat 进程中
 （3）其全部集成在一个单一的单元.
 （4）优点：3点
     <1>方便调试，代码都在一起
     <2>易于部署，所有服务都在本地容器内
     <3>中小型项目可以快速迭代，不需要太多资源
 （5）缺点：4点
     <1>可复用性差：服务被打包在应用中，功能不易复用
     <2>系统启动慢：一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长  
     <3>线上问题修复周期长：任何一个线上问题修复需要对整个应用系统进行全面升级。
     <4>系统扩展性比较差：增加新东西的时候不能针对单个点增加，全局性的增加.牵一发而动全身。

2.分布式（微服务）应用：

（1）微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法
（2）每个小型服务都运行在自己的进程中，并经常采用HTTP资源API轻量的机制来相互通信
（3） 这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署
（4）一个微服务只关注某个特定的功能
（5）优点：5点
      <1>易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单
      <2>单个微服务启动较快
      <3>局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可
      <4>技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈
           举例：技术栈
                    1.就是掌握了一堆的技术(掌握多种技术)
                    2.指将N种技术互相组合在一起(N>1)，作为一个有机的整体来实现某种目的或功能
                    3.html + css + javascript + jquery + springmvc + hibernate + spring + linux + mysql这就可以称为技术栈
       <5>按需伸缩：可根据需求，实现细粒度的扩展
 （6）缺点：3点
      <1>运维要求高：更多的服务意味着要投入更多的运维
      <2>分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
      <3>接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整

3.分布式与微服务，集群区别

  （1）分布式：
        <1>一个业务分拆多个子业务，部署在不同的服务器上
        <2>分布式中的每一个节点，都可以做集群
        <3>分布式需要做好事务管理
        <4>区别分布式的方式是根据不同机器不同业务。
  （2）微服务：
        <1>微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成
        <2>系统中的各个微服务可被独立部署，各个微服务之间是松耦合的
        <3>每个微服务仅关注于完成一件任务并很好地完成该任务
  （3）集群：
        <1>同一个业务，部署在多个服务器上        
        <2>区别集群的方式是根据部署多台服务器业务是否相同
        <3>集群模式需要做好session共享，确保在不同服务器切换的过程中不会因为没有获取到session而中止退出服务
        <4>一般配置Nginx*的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量
   （4）分布式是否属于微服务
        <1>不一定，如果一个很大应用，拆分成三个应用，但还是很庞大，虽然分布式了，但不是微服务。微服务核心要素是微小
        <2>微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务
        <3>微服务的应用不一定是分散在多个服务器上，也可以是同一个服务器     
        <4>微服务架构是分布式服务架构的子集
        <5>分布式：分散压力。微服务：分散能力
    （5）单应用与集群
        <1>整个项目所有的服务都由这台服务器提供。这就是单机结构
        <2>单机复制几份，这样就构成了一个“集群”
        <3>集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群
        <4>每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍
   总结：（1）开始单机应用
              （2）随着业务增加，单机扩展演变集群
              （3）业务继续增加，集群拆分业务功能演变分布式（微服务）   

4.分布式（微服务）子系统间通信

 远程过程调用（RPC）
          <1>将单机环境下的过程调用加以扩充后延伸到分布式系统环境
          <2>用户可以像调用本地过程一样调用不同地域的不同计算机上的过程
          <3>这种通信方法的主要优点是,程序员无需知道调用的是一个远程过程还是一个本地过程

扩展：技术与架构，业务之间的关系

通过人为创造条件，让指定的规律按照人类的意愿发生，这就是技术
举例：比如取火
   （1） 最早人类只能靠打雷等自然现象产生火。取火其实就是一个业务目标，要解决的是人类自己的问题，这就是业务，实际就是人类的利益。
   （2）这个时候人类没有生火的技术，只能靠不断的加木材，保持火不熄灭
   （3）后来人们发现了钻木取火
   （4）这个办法让人类可以自行创造火源，就产生了钻木取火的技术
   （5）但是双手快速转动木棍钻木取火，并不是所有人都能够做得到的，需要很多力量和速度，对人的要求太高
   （6）为了解决快速转动的问题，就采用弓弦来提升木棍转动的速度。
总结：
   （1）业务目标是为了取火，钻木取火这个技术的出现解决了这个问题   
   （2）钻木取火的效率不高，影响了业务（取火）的效率，就有了进一步改进的动机，改进转动木棍的方式，产生了弓弦转动木棍的技术。
技术与技术之间，有两种关系：
   （1）在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术
   （2）一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能
   （3）就会有提高效率的需求出现，要求改进这个技术
   （4）这个技术的低效率部分就会加以改进，这部分就会形成新的技术   
   （5）新技术会通过某种方式和原有的技术一起形成一个整体共同工作，使得原有的技术可以用更高的效率解决问题
   （6）要解决的主要问题（生火）并没有发生改变

1.技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益
2.技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提
3.有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务

 一般是先有业务，根据业务需求产生技术，最后才会有架构！
   （1）这些其他技术（弓弦拉动木棍），是从直接解决问题的初始主要技术（钻木取火）中分拆出来形成的
   （2）通过树状结构和主要技术（钻木取火）组合在一起，更高效的解决主要问题（生火）
   （3）这个细粒度的技术（弓弦转动木棍）往往不会和业务的主要目标（生火）发生直接的关系
   （4）不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标
 总结：（1）正是因为同一个业务，实现的中间技术很多，需要选择，才会有架构产生
            （2）架构用来连接各个技术，高效，快捷的完成目标业务
            （3）众多的技术中如何选型，目标业务如何拆分，从而产生了架构师  

1.架构师都做些什么

  （1）在软件设计阶段，做好软件“骨架”的设计
  （2）确认需求与拆分系统
        在项目开发过程中，架构师需要依据用户需求，将完整的系统拆分为子系统和组件，
        形成不同的逻辑层或服务，确定各层的接口、层与层相互之间的关系，对整个系统分层进行“纵向”分解，对同一逻辑层分块进行“横向”分解
  （3）技术选型
        通过对系统的一系列的分解，最终形成了软件的整体架构，依据整体架构需要进行技术选型
   举例：天猫这样的大型分布式网站，需要从前端(CDN、负载均衡)，再到中间应用层端的缓存集群、消息集群、文件存储集群等的选型，
         再到后端数据库(NoSQL、MySQL、Oracle等)的选型，你需要很清楚每一种技术的优劣势和应用场景，以及未来面临的挑战和风险。
         然后从业务的角度(预估访问量和业务变化)，结合起来进行选型
   （4）系统分解
         系统分解类似实际项目中的概要设计、详细设计，业务逻辑划分、子系统与主系统的关联、数据库的设计，再到应用端业务流程等，
         从技术的角度完整的拆解业务，把控好技术的细节
   （5）制作技术规格说明