一、单体利用
在软件开发晚期阶段，大家都在一个利用零碎上开发。各个业务模块之间耦合也比拟严密。软件公布也是整体公布，或者对软件进行打包公布和部署，比方java能够打包成war部署。测试也很容易，因为代码都在一起，根本不须要援用内部的关联服务。
在软件开发晚期，这种软件开发模式能适应业务的倒退，软件应用也能够失常运行。
如果你的业务倒退良好，客户需要会变得越来越多，软件性能数也会随着客户的需要变多而变多。为了实现这些性能，你必须增加很多代码。而随着业务进一步倒退，代码量势必也会越增越多。有可能 2 到 3年后，软件代码量会变得十分微小。那时软件就会变成一个十分宏大且简单的单体利用。软件外面的性能多，代码盘根错节。相似上面这种布线图：
此时可能呈现的问题：
- 打包编译会耗时很久，导致公布也很耗时。
- 代码可维护性变差，因为代码量大，逻辑简单，只有多数老员工能全副了解。代码腐化重大。
- 批改bug和减少新性能会变得艰难，可能牵一发而动全身。
- 因为下面的起因，软件扩大变得艰难
- 软件可用性危险减少。可能一个bug导致整个软件不可用。
为了解决下面的这些问题，怎么办？ 俗话说：“大事化小”，一个字，拆！ 心愿零碎能逐步进入有序状态，像上面这样：
二、利用拆分
第一步可能想到的就是拆分利用。
把一个“大泥球 ”一样的单体利用依照业务来进行拆分。比方电商，可能拆分为商品利用，订单利用，用户利用，商铺利用等等绝对比拟小的利用。
业务的进一步倒退，你可能把下面的利用做进一步拆分，变成更小的利用，以服务的模式对外提供利用。缓缓的变成了比拟小的服务-微服务。
随着软件架构的调整，能解决下面遇到的问题吗？大部分能够解决。
服务稳固的运行了一段时间，你也过了一段难受的日子。然而在应用微服务的过程中，问题也逐步裸露进去，微服务会带来什么问题呢？上面对微服务进行一些思考。
三、微服务思考
什么是微服务
维基百科定义：
微服务 (Microservices) 是一种软件架构格调，它是以专一于繁多责任与性能的小型性能区块 (Small Building Blocks) 为根底，利用模块化的形式组合出简单的大型应用程序，各性能区块应用与语言无关 (Language-Independent/Language agnostic) 的 API 集互相通信。
AWS的定义：
微服务是一种开发软件的架构和组织办法，其中软件由通过明确定义的API 进行通信的小型独立服务组成。 这些服务由各个小型独立团队负责。 微服务架构使应用程序更易于扩大和更快地开发，从而减速翻新并缩短新性能的上市工夫
微服务有哪些劣势与劣势（问题）
- 劣势：
- 利用小，可疾速编译部署
- 单个微服务维护性变高，批改容易，因为每个团队独立负责一块性能。新性能交付变快，能够疾速开发交付
- 扩展性变高，依据业务规模能够随时缩减/减少服务器规模
- 可靠性变强，能够部署很多独立的服务
- 业务解耦，依照业务边界拆分为多个独立的服务模块
- 晋升研发效率，业务拆分后，服务模块变小，在一个团队内就能够独立编写、测试、公布，放慢研发效率。
微服务有这么多劣势，那微服务是“银弹”吗？微服务不是银弹，它带来了很多劣势，同时也带来了很多劣势（问题）。
- 劣势（问题）：
- 整体复杂度变高，从哪些方面来治理这种复杂度？
- 运维变得复杂：微服务变多，怎么监控所有微服务，保障服务稳固？出了问题，怎么定位问题？
- 服务治理：微服务变多，治理复杂度变高，治理变得复杂
- 测试方面的挑战：你须要联合其余的微服务来进行集成测试
- 分布式问题：分布式数据一致性、分布式事务
- 服务保障：一个服务出了问题，如何能力不影响其余服务？
依据下面微服务定义，这些服务都是由小型独立团队负责，那团队怎么划分？公司组织架构如何调整能力适应微服务的架构倒退？这也给组织治理带来了挑战。
还有微服务的“微”，多“微”才是好的“微”？也就是微服务怎么划分，如何确定边界？
等等这些都是微服务面临的问题和挑战。
题外话：任何问题都有正反面，就像一枚硬币一样，所以思考问题要多样化，不能只思考一点。
四、总结
依据以上简略剖析，微服务的施行并不是欲速不达的事件，是随着业务的倒退而倒退，是一种逐步演进的模式。
微服务架构是为了适应业务的疾速变动，产品的疾速迭代、交付、反馈和批改，团队成员收缩而提出的一种架构解决方案。
微服务的优劣剖析能够看出，微服务并不是“银弹”，它给开发和产品带来益处的同时，自身也会带来一系列的问题。如何克服这些问题，才是施行好微服务的关键所在。
下面提到的劣势（问题），也须要建设运维开发基础设施来加以保障能力让微服务顺利运行。比方CI/CD，监控体系，配置核心等等，那DevOps是否也要同步建设？
所以胜利施行微服务并不是一件孤立的事件，它关联很多其余事件，架构、工具到团队协同，须要同步建设，它是一个系统工程。