开场白：从架构的选择可以看出你的人品，所以要慎重。当然，只是个玩笑。技术架构的选择实际上体现的是你的文化知识背景和技术的偏好，当然还有与时俱进的学习能力，还有深度思考和判断能力。反正有很多。
技术选型要从多方面考量：降低开发成本；提高研发效率
语言的选择：应该选群众基础好的、更新及时的语言
服务架构的选择
单体架构：第一代单体应用，所有的模块打包到一起部署运行；例如打包一个war包放到一个tomcat下运行，这种架构也叫巨石型应用架构，在开发小型项目上有独特优势：易于调试、部署、运维方便。
缺点：
1. 不可靠。任何模块的一个bug，可能拖垮整个应用
个人体验：一个巨型的单体应用，每次的build时间可以长达1个小时，一个小的代码改动就需要重新走一遍CICD，非常耗时。另外，写好对应如此庞大的代码的单体测试和整合测试都是非常艰巨的任务。有的组干脆就不写了，选择裸奔。这样的应用存在时间越长，危险就越有可能发生。
2. 单维扩展。只能通过运行更多的服务器水平扩展，而不同的应用服务对资源的需求不同
3. 不可持续发展。引入新的框架或语言需要重构所有业务模块，往往需要在初期就选定技术栈
后来，组里决定不能再这么干了，得拆分单体应用，改成微服务。拆分又是一件头大的事情，面对不规范的代码（光if else就能绕死），单体测试代码的缺失，你真的不敢下手拆。。。
SOA(Service Oriented Architecture)
面向服务架构，它是一种设计方法，设计上通常是自上而下的，服务间松散耦合。ESB集成不同协议的服务，做消息的转化、解释、路由从而联通各个服务，解决企业通信问题，服务松耦合、可扩展
缺点
1. ESB的存在并没有解决单体巨石应用的一些问题
2. SOA更多的面向企业服务，服务拆分粒度很大，更多的是为了复用
微服务微服务，是去中心化的SOA拓展，它强调服务彻底的组件化，一个组件就是一个产品，服务切分粒度更小，设计上更多是自下而上的。服务间通过轻量化的协议进行通信，并根据服务本身需要独立化部署
SOA和微服务的思维区别
SOA：因为单体巨石应用无法灵活扩展，且部署困难。自上而下，从运维侧视角出发，更多聚焦可维护性，兼顾可扩展性，从前后端分离切入。
微服务：因SOA服务粒度太粗，难以有效扩展，微服务应运而生。自下而上，从产品视角出发，更多聚焦可扩展性，兼顾可维护性。
业务隔离，并行开发，易于运维，单独部署
Spring框架
JDBC数据访问框架
读写效率：
JDBC原生包 10倍 > Spring JDBC 20% > MyBatis
但是JDBC原生包的使用非常不便
消息队列
性能，效率，成本
