聊聊微服务的架构与应用

1.微服务架构

微服务这个词越来越多的被提到，2014、15年的一波创业大潮，

很多创业公司需要短平快的产品开发，推动了敏捷开发、持续交付以及基于Docker的应用部署的发展，同时微服务结构也开始慢慢流行起来。

2.应用架构演进

（1）垂直应用架构

传统的LAMP架构和Spring+Struts+iBatis/Hibernate的架构都是典型的垂直应用架构，垂直应用架构学习成本低，开发产出快，测试、部署和运维比较简单，在过去的十几年中一直比较流行。
但是随着业务的发展，垂直应用架构逐渐暴露出一些缺陷，以Spring MVC架构为例，可能的表现：
1.复杂应用的开发维护成本越来越高，测试变得困难，部署效率越来越低。
2.团队沟通成本上升，协作变差，难以保证代码质量。
3.类似木桶效应，由于一些短板的存在，系统性能难以保证。
4.维护和定制变得困难，新功能上线周期变长，难以实现快速迭代。

（2）RPC架构

当垂直应用越来越多，应用之间交互不可避免，RPC可以提高业务复用及拆分。
当应用大规模服务化之后，会面临许多服务治理方面的问题。

（3）SOA服务化架构

SOA是一种粗粒度、松耦合的以服务为中心的结构，接口之间通过定义明确的协议和接口进行通信。

（4）微服务架构

微服务是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。

3.微服务架构解析

（1）微服务的架构

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起。

（2）微服务架构对比SOA

两者的主要差异如下：
1.服务拆分粒度
2.服务依赖
3.服务规模
4.架构差异
5.服务治理
6.敏捷交付

4.微服务架构的优点和缺陷

微服务的优点和缺陷就像一枚硬币的两面，要根据项目的实际情况合理的决定选用哪种架构。

（1）微服务的优势显而易见

1.避免系统无限膨胀
每个服务都很简单，只关注于一个业务功能，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
2.独立部署
由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
3.微团队独立开发，扁平化管理
由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
4.可以通过不同的编程语言与工具进行开发
不同的模块之间不用关系具体实现。
5.更好的扩展性
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

7.容错性
当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

（2）微服务架构的一些缺点

1.分布式系统的复杂性
作为一种分布式系统，微服务引入了复杂性和其他若干问题，比如网络延迟、容错性、消息序列化、不可靠的网络、异步、版本化、应用层中的负载变化等等。

2.代码重复
微服务强调小规模团队独立开发，不建议使用全局的公共类库。会在一定程度上造成代码重复。

3.测试繁琐
相比垂直应用架构，微服务的分散部署使测试变得繁琐。

5.微服务架构最佳实践

（1）使用分布式和自动化进行微服务运维

利用分布式系统的性能线性增长和弹性扩容能力，支撑大规模微服务对运维系统带来的冲击。
主要的如分布式性能数据和日志采集系统；
分布式汇总和计算框架；
分布式文件存储服务；
分布式日志检索服务等。

（2）基于Docker的容器化部署

 

参考：
《分布式服务框架原理与实践》李林峰
微服务实战：微服务架构的优势与不足