update index

1-introduction-to-microservices.md

@@ -18,7 +18,7 @@
 
 以这种风格编写的应用是很常见的。他们很容易开发，因为我们的 IDE 和其他工具专注于构建单个应用程序。这些应用程序也很容易测试。您可以通过简单地启动并使用如 Selenium 测试包来测试 UI 以轻松地实现端到端（end-to-end）测试。单体应用同样易于部署。你只需拷贝打包好的应用程序到服务器。您还可以通过运行多个副本和结合负载均衡器来扩展应用。在项目的早期阶段，它运作良好。
 
-## 走向单体地狱
+## 1.2、走向单体地狱
 不幸的是，这种简单的方法有很大的局限性。成功的应用有一个趋势，随着时间推移而变得越来越臃肿。在每个冲刺时期，您的开发团队实现了更多的用户需求，这意味着添加了许多行代码。几年之后，您的小而简单的应用将会逐渐成长为[庞然大物似的单体](http://microservices.io/patterns/monolithic.html)。为了给出一个极端的示例，我最近和一位开发者做了交谈，他正在编写一个工具用于从他们的数百万行代码（lines of code，LOC）应用中分析数千个 JAR 之间的依赖。我相信这是大量开发者在多年齐心协力下创造了这样的野兽。
 
 一旦您的应用程序成为了一个庞大、复杂的单体，您的开发组织可能陷入了一个令人痛苦的世界。敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序实在是非常复杂。对于任何一个开发人员来说，这是在太大了，这是可以理解的。最终，正确地修复 bug 和实现新功能变得非常困难且耗时。此外，这个趋势就像是往下的螺旋。如果基本代码难以理解，那么改变将不会变得正确。您最终得到的是一个巨大且不可思议的[大泥球](http://www.laputan.org/mud/)。

README.md

@@ -8,8 +8,8 @@
 ### 1、[前言](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/0-foreword.md)
 
 ### [1、微服务简介](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/1-introduction-to-microservices.md#1微服务简介)
-- [1.1、构建单体应用](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/1-introduction-to-microservices.md#1.1构建单体应用)
-- [1.2、走向单体地狱](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/1-introduction-to-microservices.md#1.2走向单体地狱)
+- [1.1、构建单体应用](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/1-introduction-to-microservices.md#11构建单体应用)
+- [1.2、走向单体地狱](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/1-introduction-to-microservices.md#12走向单体地狱)
 - 1.3、微服务——解决复杂问题
 - 1.4、微服务的优点
 - 1.5、微服务的缺点