Java项目架构演变:单体应用-SOA-微服务

单体应用

概览

所有功能全部打包在一起。大部分是一个jar包或者war包，随着业务发展功能增多，这个项目会越来越臃肿

优点

容易开发，测试，部署，适合项目初期试错

缺点

复杂性高：代码多，十万行，百万行级别。加一个小功能，会带来其他隐患，因为他们在一起

技术债务：人员流动，不坏不修，因为不敢修

持续部署困难：①由于是全应用，改动一个小功能，全部部署，会导致无关应用暂停使用；②编译部署上线耗时长，不敢随意部署，导致部署频率降低，进而导致两次部署之间功能修改变多，越不敢部署，恶性循环

可靠性差：某个小问题如：OOM会导致整个应用瘫痪

扩展受限：只能整体扩展，无法按照需要进行扩展

阻碍创新：①单体应用是以一种技术解决所有问题，不容易引进新技术。但在高速的互联网发展过程中，适应的潮流是：用合适的语言做合适的事情。比如在单体应用中，一个项目用springMVC，想换成spring boot，切换成本很高，因为有可能10万，百万行代码都要改，而微服务可以轻松切换，因为每个服务，功能简单，代码少。

SOA

面向服务架构（Service-Oriented Architecture）在这种架构中，拆分系统，把功能都定义为独立的服务，服务之间通过接口进行调用，相互依赖，最终提供一系列完整的功能。 把功能和资源转换成服务 定义标准接口，形成资源共享 ；

特点 :SOA架构中通常使用XML方式实现通讯，在高并发情况下XML比较冗余会带来极大的影响，所以最后微服务架构中采用JSON替代xml方式。 SOA架构的底层实现通过WebService和ESB（xml与中间件混合物），Web Service技术是SOA服务化的一种实现方式，WebService底层采用soap协议进行通讯，soap协议就是Http或者是Https通道传输XML数据实现的协议。

 注：ESB(企业服务总线) :简单来说是一根管道，用来连接各个服务节点。esb存在是为了集成基于不用协议的不同服务，esb做了消息转化，解释以及路由的工作，以此来让不同的服务互联互通。

微服务

微服务架构产生的原因：在传统的WebService架构中有如下问题： ①依赖中心化服务发现机制；②使用Soap(Simple Object Access Protocol)通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常喜欢重，比较占宽带传输；③ 服务化管理和治理设施不完善

微服务是什么？ 微服务架是从SOA架构演变过来，比SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，互不影响，微服务架构更加体现轻巧、轻量级，是适合于互联网公司敏捷开发。

微服务架构特征：①微服务架构倡导应用程序设计成多个独立、可配置、可运行和可微服务的子服务。 ②服务与服务通讯协议采用Http协议，使用restful风格API形式来进行通讯，数据交换格式使用轻量级json格式通讯，整个传输过程中，采用二进制，所以http协议可以跨语言平台，并且可以和其他不同的语言进行相互的通讯，所以很多开放平台都采用http协议接口。

微服务优点 ：①独立部署。不依赖其他服务，耦合性低，不用管其他服务的部署对自己的影响。 ②易于开发和维护：关注特定业务，所以业务清晰，代码量少，模块变的易开发、易理解、易维护。 ③启动块：功能少，代码少，所以启动快，有需要停机维护的服务，不会长时间暂停服务。 ④局部修改容易：只需要部署 相应的服务即可，适合敏捷开发。 ⑤技术栈不受限：java，node.js等 ⑥按需伸缩：某个服务受限，可以按需增加内存，cpu等。⑦职责专一。专门团队负责专门业务，有利于团队分工。 ⑧代码复用。不需要重复写。底层实现通过接口方式提供。 ⑨便于团队协作：每个团队只需要提供API就行，定义好API后，可以并行开发。

微服务缺点：①分布式固有的复杂性：容错（某个服务宕机），网络延时，调用关系、分布式事务等，都会带来复杂。 ②分布式事务的挑战：每个服务有自己的数据库，有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL，评论用Mongodb等。目前最理想解决方案是：柔性事务的最终一致性。 ③接口调整成本高：改一个接口，调用方都要改。④测试难度提升：一个接口改变，所有调用方都得测。自动化测试就变的重要了。API文档的管理也尤为重要。推荐：yapi。 ⑤运维要求高：需要维护 几十 上百个服务。监控变的复杂。并且还要关注多个集群，不像原来单体，一个应用正常运行即可。 ⑥重复工作：比如java的工具类可以在共享common.jar中，但在多语言下行不通，C++无法直接用java的jar包。

注：刚性事务-遵循ACID原则，强一致性。 柔性事务：遵循BASE理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。 BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

微服务架构与SOA架构区别：①微服务架构基于 SOA架构 演变过来，继承 SOA架构的优点，在微服务架构中去除 SOA 架构中的 ESB 消息总线，采用 http+json（restful）进行传输。 ②微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。 ③SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。 ④项目体现特征，微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

注：分布式 很多的节点，进程在不同的物理位置，他们之间有协作