● 面向I/O *** 作较密集、计算需求较低的简单轻量级服务的微型服务器；
● 需要较均衡I/O和计算能力的中量级负载的主流服务器；
● 需要以较高效率计算处理海量数据以支持企业核心业务运转，常常要配备高性能处理器平台和内存子系统的关键业务用服务器。
微型服务器看似并不是较关键的业务的承载平台，但却是服务器产品类别中的一个重要补充。因为它能为自己专注的应用负载带来最佳的能效表现。
如果按照外形结构的不同划分，可以将服务器分成塔式服务器、机架式服务器、刀片服务器和微服务器。
塔式服务器的外形及结构都与普通PC机差不多，但个头稍大，外形尺寸无统一标准。其主板扩展性较强，插槽很多，且机箱内往往预留很多空间，以便硬盘、电源等冗余扩展。这种服务器无需额外设备，对放置空间没多少要求，并且具有良好的可扩展性，配置也能很高，因而应用范围非常广泛。但它也有不少局限性，在需要采用多台服务器同时工作时，由于其个体较大、占用空间多，不方便管理。
机架式服务器是工业标准化产品，其外观按照统一标准来设计，配合机柜统一使用，以满足服务器密集部署需求，可节省空间，且便于统一管理。机架服务器的宽度为19英寸，高度以U为单位（1U=175英寸）。但由于内部空间限制，扩充性受限，此外，散热性也是一个需要注意的问题。在服务器托管中大都采用这种方式。
刀片服务器是一种高可用、高密度、低成本服务器平台，专门为特殊应用行业和高密度计算机环境设计，其主要结构为一大型主体机箱，内部可插上许多“刀片”，其中每一块刀片实际上就是一块系统母板，类似于一个个独立的服务器，它们可以通过本地硬盘启动自己的 *** 作系统。每一块刀片可以运行自己的系统，服务于指定的不同用户群，相互之间没有关联。而且，也可以用系统软件将这些主板集合成一个服务器集群。刀片服务器比机架式服务器更节省空间，同时，散热问题也更突出。此类产品一般应用于大型的数据中心或者需要大规模计算的领域。
微服务器是服务器领域的一个新兴的产品类别，它具有单机多节点的特点，采用热插拔模块化设计，体积小、密度高、功耗低，价格也相对便宜。同一个机架上的微服务器还可以共享电源、冷却系统，以及存储和网络连接。
微服务架构是一项在云中部署应用和服务的新技术。
大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务架构相关介绍：
微服务可以在“自己的程序”中运行，并通过“轻量级设备与>
在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。
如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。
服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
（一款免费开源的JAVA互联网云快速开发平台）微服务分布式代码生成的敏捷开发系统架构。项目代码简洁,注释丰富,上手容易,还同时集中分布式、微服务,同时包含许多基础模块和监控、服务模块。演示版地址：>现在一聊到容器技术，大家就默认是指 Docker 了。但事实上，在 Docker 出现之前，PaaS社区早就有容器技术了，以 Cloud Foundry、OpenShift 为代表的就是当时的主流。
那为啥最终还是 Docker 火起来了呢？
因为传统的PaaS技术虽然也可以一键将本地应用部署到云上，并且也是采用隔离环境（容器）的形式去部署，但是其兼容性非常的不好。因为其主要原理就是将本地应用程序和启停脚本一同打包，然后上传到云服务器上，然后再在云服务器里通过脚本启动这个应用程序。
这样的做法，看起来很理想。但是在实际情况下，由于本地与云端的环境差异，导致上传到云端的应用经常各种报错、运行不起来，需要各种修改配置和参数来做兼容。甚至在项目迭代过程中不同的版本代码都需要重新去做适配，非常耗费精力。
然而 Docker 却通过一个小创新完美的解决了这个问题。在 Docker 的方案中，它不仅打包了本地应用程序，而且还将本地环境（ *** 作系统的一部分）也打包了，组成一个叫做「 Docker镜像 」的文件包。所以这个「 Docker镜像 」就包含了应用运行所需的全部依赖，我们可以直接基于这个「 Docker镜像 」在本地进行开发与测试，完成之后，再直接将这个「 Docker镜像 」一键上传到云端运行即可。
Docker 实现了本地与云端的环境完全一致，做到了真正的一次开发随处运行。
一、容器到底是什么？
容器到底是什么呢？也许对于容器不太了解，但我们对虚拟机熟悉啊，那么我们就先来看一下容器与虚拟机的对比区别：
上图的左侧是虚拟机的原理，右侧是Docker容器的原理。
虚拟机是在宿主机上基于 Hypervisor 软件虚拟出一套 *** 作系统所需的硬件设备，再在这些虚拟硬件上安装 *** 作系统 Guest OS，然后不同的应用程序就可以运行在不同的 Guest OS 上，应用之间也就相互独立、资源隔离了，但是由于需要 Hypervisor 来创建虚拟机，且每个虚拟机里需要完整的运行一套 *** 作系统 Guest OS，因此这个方式会带来很多额外资源的开销。
而 Docker容器 中却没有 Hypervisor 这一层，虽然它需要在宿主机中运行 Docker Engine，但它的原理却完全不同于 Hypervisor，它并没有虚拟出硬件设备，更没有独立部署全套的 *** 作系统 Guest OS。
Docker容器没有那么复杂的实现原理，它其实就是一个普通进程而已，只不过它是一种经过特殊处理过的普通进程。
我们启动容器的时候（docker run …），Docker Engine 只不过是启动了一个进程，这个进程就运行着我们容器里的应用。但 Docker Engine 对这个进程做了一些特殊处理，通过这些特殊处理之后，这个进程所看到的外部环境就不再是宿主机的那个环境了（它看不到宿主机中的其它进程了，以为自己是当前 *** 作系统唯一一个进程），并且 Docker Engine 还对这个进程所使用得资源进行了限制，防止它对宿主机资源的无限使用。
那 Docker Engine 具体是做了哪些特殊处理才有这么神奇的效果呢？
二、容器是如何做到资源隔离和限制的？
Docker容器对这个进程的隔离主要采用2个技术点：
弄清楚了这两个技术点对理解容器的原理非常重要，它们是容器技术的核心。
下面来详细解释一下：
三、容器的镜像是什么？
一个基础的容器镜像其实就是一个 rootfs，它包含 *** 作系统的文件系统（文件和目录），但并不包含 *** 作系统的内核。
rootfs 是在容器里根目录上挂载的一个全新的文件系统，此文件系统与宿主机的文件系统无关，是一个完全独立的，用于给容器进行提供环境的文件系统。
对于一个Docker容器而言，需要基于 pivot_root 指令，将容器内的系统根目录切换到rootfs上，这样，有了这个 rootfs，容器就能够为进程构建出一个完整的文件系统，且实现了与宿主机的环境隔离，也正是有了rootfs，才能实现基于容器的本地应用与云端应用运行环境的一致。
另外，为了方便镜像的复用，Docker 在镜像中引入了层（Layer）的概念，可以将不同的镜像一层一层的迭在一起。这样，如果我们要做一个新的镜像，就可以基于之前已经做好的某个镜像的基础上继续做。
如上图，这个例子中最底层是 *** 作系统引导，往上一层就是基础镜像层（Linux的文件系统），再往上就是我们需要的各种应用镜像，Docker 会把这些镜像联合挂载在一个挂载点上，这些镜像层都是只读的。只有最上面的容器层是可读可写的。
这种分层的方案其实是基于 联合文件系统UnionFS（Union File System）的技术实现的。它可以将不同的目录全部挂载在同一个目录下。举个例子，假如有文件夹 test1 和 test2 ，这两个文件夹里面的文件 有相同的，也有不同的。然后我们可以采用联合挂载的方式，将这两个文件夹挂载到 test3 上，那么 test3 目录里就有了 test1 和 test2 的所有文件（相同的文件有去重，不同的文件都保留）。
这个原理应用在Docker镜像中，比如有2个同学，同学A已经做好了一个基于Linux的Java环境的镜像，同学S想搭建一个Java Web环境，那么他就不必再去做Java环境的镜像了，可以直接基于同学A的镜像在上面增加Tomcat后生成新镜像即可。
以上，就是对微服务架构之「 容器技术 」的一些思考。
码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。
废话不多说，直接来干的。这里介绍一套成熟的方案。
gitlab(代码管理)+jenkins(持续集成)+k8s(服务管理)
其中涉及到的技术细节:dockerindockermakefile
gitlab使用介绍
gitlab是一款类似github的开源代码管理软件，可在公司内网，直接搭建一套私有代码仓库，适合团队多人开发，具有完善的分支管理、角色管理、issue、里程碑等。是非常优秀的一款软件。
jeknis使用介绍
这是一款开源持续集成软件，说人话就是使用他可以自动化部署服务。其具有gitlab相关的插件，安装后可直接对接gitlab，当gitlab发生push或者merge代码事件，会通知jeknis去完成最新推送的代码的镜像构建和部署。
推荐上面说的两款技术和jeknis混合使用。
1dockerindocker技术。顾名思义就是docker里面运行docker，简单点直接用dockerfile在jeknis镜像的基础上安装docker客户端或者k8s客户端。这样我们在容器中就可以直接调用宿主机的docker命令或者k8s命令。这对我们使用jenkins执行部署脚本，通知k8s或者docker部署服务，非常方便。
2makefile之所以介绍这款他，是因为其具有一个绝佳的功能，可以检测文件内容是否发生变化，这样对于微服务架构，其配合jenkins，无需指定什么，就可以部署上发生文件变化的微服务。而不会影响到其他服务。
k8s使用介绍
这款当红炸子鸡，相信大家耳闻已久。其实现了对docker的管理和编排。配合上共享存储和其服务自动重启机制，可以让我们的服务无当机。
对于docker内部服务的暴露推荐ingress+service
docker镜像管理推荐harbor。
以上完整的自动化开发部署环境，有兴趣的可以自行学习相关内容，进行搭建测试。
我们公司使用的就是微服务加分库分表，一般来说如果应用系统出现性能瓶颈或者业务代码耦合过重，可考虑使用微服务架构，而后端的数据库通常使用读写分离，双主互备或者是分库分表来实现性能的提升和数据服务的高可用。
在数据分布在不同的数据库服务器的带来良好性能的同时，新的问题也随之而来，比如说数据一致性的保证，性能监控，数据存取复杂等，而较为突出的就是数据跨库问题！数据分布在不同的节点上，导致原来的连接查询需要跨库，字段的主键难以保证唯一，跨库的事务处理复杂，下面逐一解决:
1，连接查询(join)问题:因为库表分布在不同的机器上，连接查询失效。
解决办法:
①，代码解决:根据某个字段进行hash的方式进行分库分表，保证落在一个库中的类似表中(比如aa_00t_user_0000和aa_00t_member_0000)，然后基于这样的规则在代码中进行连接查询语句书写！
②，同步:将常用的，需要的字段同步到一个库中进行联合查询！
③，冗余:在一个库中冗余更多的连接查询需要的字段，保证全部数据都能查询到！
2，唯一主键:如果使用传统的自增等方式，多库中的主键id势必重复，所以需要对唯一性加以控制！
解决方法:UUID(根据机器ID，时间等)，redis(单线程保证不重复)，snowflake算法！
3，分布式事务:
1，TCC:try控制业务代码流程，Confirm确认事务的正确性，cancel取消失败的事务！
2，基于消息系统的一致性方案:单节点事务完成后，通过发送消息保证事务提交，如果失败可通过重试，任务补偿等方式保证数据一致性！
总的来说，分布式系统有着很多以往不存在的问题，还需要具体问题具体分析，可一起交流，更多的技术分享，敬请关注。。。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）