微服务的优势

基于Google的K8S的崛起，很多人有已经用上了微服务相关的产品，这个思想很好，他可以解决我们单实例中很多现实问题。

我们看看单实例有什么样的问题：

1、我们之前的编写的服务都是单体服务，或者是单实例的方法，这样的会带来几个问题：当高并发的时候但是使用资源不合理分配，有时候会看到有一些业务运行占用率很低，其他的业务占用率非常高，导致高并发的内容直接就把服务相关所有的资源全部耗尽，使得之前提到的未很多资源的云业务同样无法使用。这是我们有时候不能调节的，我们可以无限大的提高硬件的整体能力，但是我们去不能提高软件真正优化能力，对于运维人员将是一个极大的挑战，这个挑战也是一个巨大硬件成本，举一个子：当报销业务挑战窗口期一般都是在年底，那个时候很多人都在报销，为了执行本年度的预算，这个时候报销系统承载很大的业务，但是核算、预算编制等业务却是在一个不是很紧急的时间段里。预算在执行期，还没有发放期，核算还没有开启。就是这个场景就可以让一个简单的报销系统处于一个很尴尬的局面，将数据库和业务系统处理能力消耗到极限。这个时候我们非常期望可以将报销、核算、预算等业务真正的分离，将报销的服务模块升级，不需要对整体升级。对需要的内容进行升级，升级的配置也可以做到按需能力。

2、在我们所有的业务过程中经常会遇到有一些业务会经常变更，经常发版，但是每一次单实例的时候我们却要整体进行打包，发布。有的时候还不能做到版本的统一，我们也期望将我们一个很大的业务进行拆分，我们每一个人只关注自己的部分，不停的迭代我们自身的业务需求，将逻辑互联的关系通过接口定义给予输出、约定。我们在实际的过程中又如何能做到呢？

好像我们没有手段可以解决这个两个问题，我们没有相关的技术，我们的技术都是单实例的进行，单实例在管理上有时候又面临一些很复杂的管理情况，通过简单的管理手段有时候无法有效的统一管理。我们需要工具，我们需要方法。这个时候Google就提出来了K8S这个工具和方法。

我们再看看K8S的好处：

1、微服务的提出也意味着去中心化可以实现，我们不再关注我们每一个具体的实现内容，开始关注每一个分散的业务。去中心化有许多不同的方式。在最抽象的层次上，这意味着世界的概念模型将在系统之间有所不同。在跨大型企业集成时，这是一个常见问题，客户的销售视图与支持视图不同。在销售视图中，一些被称为客户的东西可能根本不会出现在支持视图中。那些有可能具有不同属性和(更糟糕)的共同属性，其语义略有不同。

2、除了关于概念模型的去中心化决策之外，微服务还分散了数据存储的决策。尽管单体式应用程序在存储持久性数据时更偏向单一的逻辑数据库，但企业通常更倾向于在各种应用程序中使用单一数据库 —— 这些决策中的很多都是由供应商的与许可授权相关的商业模式进行驱动的。微服务更偏向于让每个服务管理自己的数据库，或是相同数据库技术的不同实例，或是完全不同的数据库系统 —— 一种叫做 Polyglot Persistence 的方法。你可以在单体应用中使用 polyglot persistence，但在微服务中它使用得更频繁。

3我们发现由持续交付和部署而导致自动化程度提高的一个副作用是创建有用的工具来帮助开发人员和操作人员。用于创建工件、管理代码库、创建简单服务或添加标准监测和日志记录的工具现在很常见。网络上最好的例子可能是Netflix的Netflix开源工具系列，但也有其他的包括我们广泛使用的Dropwizard。一个单体式应用程序将通过这些环境非常愉快地构建、测试、推动。事实证明，一旦你对单体式应用的生产路径做了投入，那么部署更多的应用程序似乎不再那么可怕。请记住，CD 的目标之一就是让部署变得枯燥，所以无论它是一个还是多个应用程序，只要它仍然枯燥，那就是并不重要的。我们看到团队频繁使用的基础设施自动化的另一个领域是管理生产环境中的微服务。与我们之前的断言相反，只要部署是很枯燥的，单体式和微服务之间没有太大的区别，每个部门的运营环境可能会有惊人的不同。

我们先介绍这么多，以后我们再逐步介绍K8S相关内容。