转载

微服务思考(01)：什么是微服务？微服务的优势和劣势

一、单体应用

在软件开发早期阶段，大家都在一个应用系统上开发。各个业务模块之间耦合也比较紧密。软件发布也是整体发布，或者对软件进行打包发布和部署，比如java可以打包成war部署。测试也很容易，因为代码都在一起，基本不需要引用外部的关联服务。

在软件开发早期，这种软件开发模式能适应业务的发展，软件应用也可以正常运行。

如果你的业务发展良好，客户需求会变得越来越多，软件功能数也会随着客户的需求变多而变多。为了实现这些功能，你必须添加很多代码。而随着业务进一步发展，代码量势必也会越增越多。有可能 2 到 3年后，软件代码量会变得非常巨大。那时软件就会变成一个非常庞大且复杂的单体应用。

此时可能出现的问题：

打包编译会耗时很久，导致发布也很耗时。
代码可维护性变差，因为代码量大，逻辑复杂，只有少数老员工能全部理解。代码腐化严重。
修改bug和增加新功能会变得困难，可能牵一发而动全身。
由于上面的原因，软件扩展变得困难
软件可用性风险增加。可能一个bug导致整个软件不可用。

为了解决上面的这些问题，怎么办？

二、应用拆分

第一步可能想到的就是拆分应用。

把一个“大泥球 ”一样的单体应用按照业务来进行拆分。比如电商，可能拆分为商品应用，订单应用，用户应用，商铺应用等等相对比较小的应用。

业务的进一步发展，你可能把上面的应用做进一步拆分，变成更小的应用，以服务的形式对外提供应用。慢慢的变成了比较小的服务-微服务。

随着软件架构的调整，能解决上面遇到的问题吗？大部分可以解决。

服务稳定的运行了一段时间，你也过了一段舒服的日子。但是在使用微服务的过程中，问题也逐渐暴露出来，微服务会带来什么问题呢？下面对微服务进行一些思考。

三、微服务思考

什么是微服务

维基百科定义：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

AWS的定义：

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间