1、轻量级架构概述

1.1.1、前言

当下，互联网应用呈高速发展的趋势，要想不被市场淘汰，就必须与时间赛跑，故而，快就成了所有互联网公司产品的特征，只有率先推出产品，才能获取主动权。

1.1.2、开发模式

基于快速开发的诉求，那么怎样才能实现快速开发呢？以下将介绍几种互联网项目中常用的开发模式。

⭐渐进式开发
即将一个长期的大需求分解为若干个短期的小需求，只考虑近几个月或几个星期的需求，针对短期进行设计，而后开发，这就是所谓的“渐进式开发模式”
瀑布式开发
瀑布式开发是通过设计一系列阶段顺序展开的。从需求分析到产品发布和维护，每个阶段都会循环反馈，若其中某一环节出现了问题，就需要返回到上一阶段并进行修改。虽然这种开发模式稳定性好，但相对渐进式来说，开发周期实在是太长了，假若一款产品的开发时间长达数年，谁又能保证几年后该产品还能被用户所接受呢？
⭐敏捷式开发
敏捷式与渐进式类似，敏捷开发将产品的开发周期划分为若干个“迭代（各种小版本，例如手机app时常要进行更新）”。一般一个迭代为4周或2周，开发团队全力完成当前迭代所确定的目标。在迭代之后，会发布一个可用的版本，交付给用户使用。

1.1.3、开源技术

即开放源代码的技术。例如Tomcat、Mysql...对于初创的互联网公司来说，使用开源技术可以节省很大一笔技术开支。同时，开源技术的源代码是公开的，互联网公司可以根据自身开发需求对其源码进行分析；但是，能看到源码并不意味着可以解决所有问题。开源技术在技术支持上并不能与闭源技术相提并论，原因在于开源技术依赖于开源社区的支持(俗称靠爱发电)，而闭源技术是花钱买的，有专业的技术团队，他们会提供售后

1.1.4、微服务

微服务架构通俗来说就是分工合作，相比于敏捷式的开发，微服务架构侧重于将整个软件划分为若干不可分割的原子服务，例如A司有一个互联网商城项目，该项目可以划分为用户信息模块、商品管理模块…每一个模块作为一个原子业务交由不同的团队进行开发，这些业务之间由良好的接口和契约进行连接(约定大于配置)。

1.1.5、高并发

大型互联网应用往往有着非常高的并发量，过高的并发将会带来以下问题:

→用户角度
页面加载慢、功能操作后响应时间长、功能无法使用等。
→开发者角度
接口超时、线程池耗尽、数据库连接池耗尽、数据库获取连接时间长、缓存雪崩、导致其他系统功能和业务受到影响等。

如何抵御突如其来的流量洪峰，是每个运维人员需要思考的问题！
其中常用的一种解决方案是：将经常需要访问的数据缓存起来，这样在下次查询的时候就能快速地找到这些数据。

1.2、传统企业级应用技术的不足

JAVA，作为一门受欢迎的编程语言，在经历了20多年的发展后，已然成为了企业级应用开发的首选语言。java以其稳定性著称，特别是 “Write Once，Run Anywhere” 的特性，非常符合互联网企业快速推出产品的需求。

但是，传统的java企业级所使用的技术，并不能适应当前互联网公司的发展需求，其不足之处总结如下：

1.2.1、规范不实用

Java企业针对企业级应用市场推出的规范称为JavaEE.
传统的JavaEE系统框架是臃肿、低效和脱离现实的，当时的SUN公司推崇以 EJB 为核心的JavaEE开发方式。关于EJB，其官方的说法是：
关于EBJ的详细内容请参考该文章

商务软件的核心部分是它的业务逻辑。业务逻辑抽象了整个商务过程的流程，并使用计算机语言将他们实现。J2EE对于这个问题的处理方法是将业务逻辑从客户端软件中抽取出来，封装在一个组件中。这个组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实现业务逻辑，而客户端软件的功能单纯到只负责发送调用请求和显示处理结果。在J2EE中，这个运行在一个独立的服务器上，并封装了业务逻辑的组件就是EJB（Enterprise JavaBean）组件。

传统JavaEE应用的开发效率是低下的。应用服务器厂商对各种技术的支持并没有真正统一，而出现这些问题的原因，是JavaEE和EJB的设计都是"以规范为驱动"的。但这些规范并没有针对性的解决问题

1.2.2、学习成本太高

传统JavaEE的很多规范都是违反 “帕累托法则”(二八法则) 的，是指花较少的成本(10%-20%)解决大部分问题(80%-90%)。EJB的问题就在于，它违背了这个法则——为了满足少数情况下的特殊要求，给大多数使用者强加了不必要的复杂性，使开发者难以上手（EJB的编程模型非常复杂，要使用EJB需要继承非常多的接口，而这些接口在实际开发中并不是真正为了解决问题）
通俗来说：就是EJB为了能满足少部分要求，使日常的80%-90%一般要求的满足变得更加复杂

1.2.3、不够灵活

EJB依赖于容器，所以EJB在编写业务逻辑时是与容器耦合的，编程模型不够灵活。因为编写程序需要依赖于具体的容器实现，所以"Write Once,Run Anywhere"变成了"一次编写，到处重写"当容器变化时，相应的容器实现逻辑也得变化，特别是实体bean，基本上迁移了一个服务器，就需要重新编写，相应的测试工作量也增加了。