微服务架构实践之服务器架构演变探究

摘要: 总结一下后端服务器架构的发展过程
从根源上学习我们的微服务架构

###引子



在服务器开发过程中我们的不同过程中应该使用怎样的架构
分布式架构和单一应用的架构又有何区别和优势
为了更好的学习和使用我们的微服务架构我们从架构的演变讲起

单一应用架构

我们以一个电商网站为例
它可能包含多个模块 订单 支付 商品等，在单一应用的架构
我们的开发人员所有模块都集中在同一个项目中所有代码放在同一个容器中运行
连接的也是同一个的数据库

这样的好处是在前期代码比较好复用 数据库事物处理简单,部署也比较容易
缺点也显而易见开发上讲不容易模块化，对集群的支持性不好
伴随着并发量的提升带来的可扩展性会越来越低
并且随着代码量的不断增加维护成本越来越高了部署和升级和前期成反比

不过在项目的初期需要快速建立原型的时候，这样的架构对于开发来说更加高效，
并且架构并非一蹴而就，可以随着我们项目的变化而演变的。

** 垂直应用架构**

为了解决单一应用架构的问题
我们使用垂直应用的架构，把各个业务进行拆分 如商品 支付等都使用单独的模块进行开发
这样的好处是可以模块化开发，解决单一应用后期业务复杂难以维护的问题
并且可以分开部署从而解决单一应用的一部分扩展性问题

但是垂直应用的缺点也显而易见，相同功能的代码难以复用
特别是异构系统，这样对系统的可维护性和升级又带来了新的难题

面向服务的架构

为了解决垂直应用架构相同功能难以复用的问题
我们使用分布式应用的架构，把相同的逻辑进行提取，形成服务，对外使用
也就是我们SOA（面向服务的架构）的由来
这样的方式提升了系统的可维护性，降低了升级的难度，提升了系统的稳定性，也使分工更加明确
对模块化开发更加友好
在应对高并发的情况下，通过增加特定的服务灵活更针对性的解决
对于后期的扩展和维护也提供了相对的保证

###** 微服务**

最后引出了我们现阶段最流行的微服务架构
很明确的一点是微服务是SOA的一种延续 都是面向服务的一种方式

从部署方式上，微服务通常应用Docker技术，通过自动化方式独立部署，
每个服务运行在自己的进程中，通过轻量的通讯机制进行联系

其中最大的区别是传统的SOA一般以ESB为核心，大量的WS标准实现
而微服务是去ESB、去中心化、分布式的，微服务的服务拆分力度更细，甚至小到无法拆分
通过服务的组合，重用来实现业务，而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度，微服务更多为了可扩充性、负载均衡以及提高吞吐量而去分解应用，从而实现真正意义上的组件化开发，每个服务运行在自己的进程中，通过轻量的通讯机制进行通信

最后微服务解决了问题的同时也会带来新的问题
比如服务之间无法保证强一致性，当然没人愿意使用分布式事物，近而追求最终一致性
多了一层服务层，架构实际上是更复杂了，需要引入一系列机制对服务进行管理
又引出了服务之间的调用，服务的注册与发现
服务化之后，随着规模的扩大，一定要考虑服务治理，否则服务之间的依赖关系会乱成麻
服务的粒度细了以后部署起来又麻烦了起来，所以又引入了Docker之类的devops工具

至于如何实施微服务，面向服务架构依赖的 服务之间的调用，服务的发现，服务的治理，服务的部署
甚至服务监控 服务容错 分布式事物 实时计算 等又该如何实施，我们将在下面的一系列文章中逐一分析