别再扯微服务了，咱整点有用的行不

前言

最近SOA、Agile、Cloud、DevOps、Microservice等这些概念甚嚣尘上，追求务实的程序员兄弟们也是被折腾得够呛。对于这些概念，如果你不去了解，显得很low；等你去了解了，又发现不知所云。免不得爆一句粗口：真tm瞎扯淡...吐槽归吐槽，下面还是一起看看，微服务到底说的是啥？

微服务是啥

别急，先来看看微服务是怎么做的？

传统软件开发，经典的3层结构，代码达成war包，部署在j2ee容器（tomcat/jboss）里即可。

 

乍一看，没毛病啊，咱这几年都是这么整的，系统也玩得很溜啊。

确实，在业务相对简单的场景下，这样做确实没啥大问题。但是当业务膨胀到一定级别，比如一个大的crm，涉及几十个大功能点。这时候怕是任何一位开发同学想改点代码都感觉有点菊紧吧。

某官方给出的缺点，可参考下：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求

 

 

再来看看，所谓的微服务是怎么做的

 

1个应用拆成3个应用就叫微服务了？没错，简单来说， 微服务的目的是根据业务有效的拆分应用，实现敏捷开发和部署 。

 

微服务的一些特点，慢慢体会吧：

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）
• 自动化运维（DevOps）
• 容错
• 快速演化

 

微服务怎么实践

理论很丰满，现实很骨感，具体怎么落地啊？这需要回答下面几个问题：

• 客户端如何访问这些服务？
• 服务之间如何通信？
• 这么多服务，怎么找?
• 服务挂了怎么办？

解决了上述问题后，你会发现微服务的优点和挑战一样多。

优点

• 每个服务足够内聚，足够小，代码容易理解、开发效率提高
• 服务之间可以独立部署，微服务架构让持续部署成为可能；
• 每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；
• 容易扩大开发团队，可以针对每个服务（service）组件开发团队；
• 提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；
• 系统不会被长期限制在某个技术栈上。

挑战

• 开发人员要处理分布式系统的复杂性
• 服务管理的复杂性
• 应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。

微服务对我们的触动我觉得更多的是思维上的，对于微服务架构， 技术上不是问题，意识比工具重要。