架构

上周六参加了一场由淘宝的架构师，曾宪杰先生主讲的淘宝网架构分享。然后马上就出差了，一直没来得及总结，今晚比较有空，把这次听到的比较有启发的观点记录一下 一、为什么stateless比较有利于实现水平伸缩 关于什么是stateless的扫盲，见这个贴： http://kyfxbl.iteye.com/blog/1831869 一般有一个共识，就是把应用做成无状态的，会比较容易实现水平伸缩。但是以前一直有一个想法，就算应用是有状态的，也可以做成水平伸缩：只需要在负载均衡那里做一个session绑定就可以了，根据某种标识，把请求固定地发送到特定的server上 但是相对于有状态，stateless是更好的，主要有3个原因： 1、负载均衡不需要做session绑定，也就可以用更简单的算法，比如随机、取模等，把请求分配到任意server上，因此相对于session绑定的做法，性能会比较好 2、也是性能的问题，在7层网络模型中，session位于第7层，负载均衡如果是基于session的算法来决定要怎么分发请求，性能的损耗也会比较大 3、如果某一台server down掉了，后续的请求就没法继续往这台server发了，影响可用性 二、为什么淘宝开发session框架 如果将请求所需的信息，都放在cookie里，确实就不需要session框架了，而且也比较容易实现stateless

公众号从开始推文到现在也有一些时日了， 感谢一直以来，各位小伙伴们对民工哥公众号的关注与支持， 好多小伙伴们一直以都非常热心帮助转发、点赞、留言加以支持，再次感谢！！2018年也将过去一大半了， 民工哥仍然会坚持自己的初衷，持续输出一系列相关的干货文章（不仅限于运维，更多侧重于各类知识点、技术面的扩充，如：数据库、高并发、大流量、架构类等）。 目前呢，由于文章较多，对于小伙伴的阅读与查找比较不太方便，因些谨以此文将前面的文章按照一定的分类加改整理出来，方便大家后续查找与阅读。 同时也欢迎小伙伴们转发分享与推荐（ 此篇文章足足整理了4小时 ）！整理不易，如有帮助，请点赞，转发支持一下，各位老铁们。 公众号相关： 民工哥的十年故事续集：杭漂十年，今撤霸都！ 重磅消息｜民工哥公众号更名啦......... 2017年目录大全： 精心整理｜公众号文章目录大全 （一） 注：此目录整理文章截止时间为2018年3月19号 1、Docker容器系列文章 [容器技术] Docker容器技术入门（一） [ 容器技术]Docker容器技术入门（二） 这20个Docker Command，有几个是你会的？ Docker，你到底知道多少？ 容器技术｜Docker三剑客之Compose 容器技术｜Docker三剑客之docker-machine 打造高逼格、可视化的Docker容器监控系统平台 2

　　中国邮政储蓄银行(以下简称：邮储银行)于2007年3月20日正式挂牌成立，是在改革邮政储蓄管理体制的基础上组建的商业银行。相对于其他国有银行，邮储银行成立时间较晚，要想赶上别人，就要另辟蹊径。2014年10月26日，邮政储蓄系统逻辑集中工程全面切换上线引发业内广泛的关注，之前就有传闻，政府推动银行弃用IBM高端服务器，互联网行业能“去IOE”,银行业到底能不能“去IOE”? 　　在开始本文前，为方便大家阅读理解，先解析几个相关知识点： 　　1、什么是“IOE”?I=IBM(服务器提供商)，O=Oracle(数据库软件提供商)，E=EMC(存储设备提供商)，三者构成了一个从软件到硬件的企业数据库系统。由这三驾马车构成的数据库系统几乎占领了全球大部分商用数据库系统市场份额。尤其是在金融行业广泛地使用这套系统。 　　2、“IOE”架构(银行架构)：集中式架构 + 闭源商用系统为基本特征。集中式架构就是核心业务99%都是运行在 1-2 台大型机上(其中有一台服务器是为了当第一台挂掉的时候顶上)。而且IOE提供了应用程序以外的所有的"基础软件",包括操作系统,中间件,数据库等.这些"基础软件"的源代码一般都是不公开的.当然,应用程序还是要银行的人自己来开发。主要代表四大银行。 　　3、“去IOE”架构(互联网架构)：分布式架构 + 开源系统为基本特征。也就是说

From InfoQ “关于架构优化和设计，架构师必须知道的事情 http://www.infoq.com/cn/articles/architecture-optimization-and-design-the-architect-must-know ” 大家可以了解一下“如何实践？”部分中提到的技术。文章也提到了“熔断”、“隔离”这些思想。在隔离方面，文章重点提到了 Docker。技术背后的思想是有相通性的，Docker 实现了进程级的隔离，而 Hystrix 实现了线程级的隔离。文章提到的技术都是各领域有代表性的。 来源： oschina 链接： https://my.oschina.net/u/1158769/blog/676639

初始简单架构结构 适用于前期用户少，访问少，所有的硬件软件资源都集成在一部服务器上面，对于一些小型的网站，要求并发比较少的可以满足。 数据库一般使用的是MySQL，开源免费易操作。但是可能WEB逻辑多时，需要多次查表或者更新的时候，读写速度就不太好了，瓶颈在数据库层。 可以调优MySQL，增加MySQL缓存等。下面是初始架构的升级版，增加memcached缓存来提高WEB应用的处理访问速度。 初始简单架构结构升级版 web应用需要修改，将取数据库的操作先去取memcached，然后再操作数据库。更新数据时也需要更新memcached和数据库。对web应用需要做的事情会更多。 在改进web应用时可以对某些耗时间特别长的逻辑做相应的改动。 这种架构的故障风险较大，memcached挂起了，会造成更长的访问时间。这个可以通过配置 memcached.socketTO 来做一些事情。 由于应用服务、数据库服务和缓存服务都在一部服务器上，风险大大增加。下面将对服务进行分离。 初始简单架构结构服务分离版 缓存可以放在应用服务器本地缓存里，也可以独立缓存服务器出来。 服务器分离后，各个服务器之间的交互会被网络带宽制约，这个是需要注意的。 如果任一台服务器挂了，会对整个服务都有影响，具体问题具体分析。 主从架构结构 采用负载均衡搭配分发，web应用搭建两部web服务器，缓存服务器一块

  随着互联网+、智能制造等大数据应用的发展，传统的企业信息化单体架构必定绕不过以下两个坎： 单机资源瓶劲造成系统响应慢，需要高成本升级硬件来解决； 单机故障造成系统不可用，需要较长的时间来恢复故障。   所以将来的企业信息化基础架构必定是分布式的，AppBoxFuture设计之初就确立了必须满足 简单、低成本 的分布式架构原则，能够利用普通硬件构建具备横向扩展能力的集群。作者最近在设计与实现集群的运维管理功能，下面让我们来体验已实现的部分功能。 一、测试环境 二、创建集群 1. 启动集群： 在VM1上执行： sudo ./appbox --init=10.211.55.3:9000 --peer=1.1.1 在VM2及VM3分别执行： sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.2 sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.3 执行完后，打开浏览器输入网址“ http://任意节点:5000/ops”进入运维管理登录界面，用户名：Admin 密码：760wb，可以看到集群包含3个节点，其中第一个是元数据节点(MetaNode)。 运维管理系统由框架自身实现，可以自由修改相关模型进行自定义。 2. 提升副本因子： 依次点击“SetAsMeta

为什么人人都想成为架构师？不外乎这几点：能力强，工资高，有底气。但是有80%的程序员是成不了架构师，这说明架构师的稀缺性。今天就带你走进架构师世界，帮助你更好了解什么是架构师必备技能。 架构师需具备的特殊能力？ 想要成为一名架构师，必须具备快速解决系统故障的能力，和可以在项目中做到统筹兼顾。因此，在技术要求方面，像Linux/ WebServer(Apache或Nginx)/ MYSQL 等基础服务的配置，优化和故障排查，根据不同的环境和要求，需要具备更多的如Memcached,NOSQL, 等服务的配置、优化和故障排查。都需要掌握和理解。除此之外，必须精通至少一门语言，如 PHP。掌握其他一些数据分析和日志分析的能力。 到了架构师这一层面，要做的是解决现实碰到的问题，包括技术的问题，产品的问题，实现系统性能的最优化，系统稳定性的保障等。此时衡量一个人的能力，不是能写多少代码，实现多少种算法，而是是否能用最快速的方法，有效地解决当前的需求或故障。 技术不是唯一？ 有一定经验的程序员都清楚，在工作中必须要有强大的自学能力，没有人会手把手的教给你所有的东西。很多技术都是自己摸索学习，想成为架构师不是懂了一大堆技术就可以。技术只是解决问题的基础、是工具，它只是帮助程序员在遇到问题时懂得如何提解决方案。 我们要明白，架构师是做什么？ 首先，出具针对性解决方，即“1+1=2”。针对业务特点

微服务架构，这 5 年左右一直被认可，是软件架构的未来方向。需要大家理解的是，为什么需要服务化。比如微服务架构对企业来说，带来什么价值？有啥弊端？ 这里浅谈一下微服务架构，主要还是在理解 Why ：为什么需要服务化？ 一、对微服务架构的理解 1.1 微服务架构 微服务架构，主要是多了个 “微”。亚马逊有个粗粗的定义：一个微服务应用工程的所有开发、测试、运维加起来大约 6 到 8 个人，只需要两个披萨就可以聚餐了。 反例：不是一个 Service 类组成的应用工程，发布成服务就是微服务。这样分的太小，理解微服务就很片面。杭州某金融大厂，曾经分的很细，造成了运维测试成本巨大。开始分了合，折腾... 1.2 为啥需要微服务？ 由 SOA 架构 -> 微服务架构的转变，得理解为什么微服务架构被广泛提到并实践。它解决了什么问题，带来了什么价值？ 传统企业或者很多企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。整体存在的问题是： 扩展性差 可靠性不高 维护成本还很大 重复轮子很多 那么这些问题，可以想到的解决方案就是： 组件化 服务化 微服务架构，将各个组件或者模块分散到各个服务中，对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。什么是组件化？ 组件化，即将一个大系统，按照一定的业务或者技术维度关注形式，拆分成独立的组件。目的是为了分而治之

微服务 强调的是服务的大小，它关注的是某一个点，是具体解决某一问题/提供落地对应服务的一个服务应用， 狭义的看，可以看做Eclipse里面的一个个微服务工程/Module 微服务架构 微服务架构是一种架构模式，它提倡将单一应用划分成一组小的服务，服务之间相互协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相协作(HTTPPAII的RESTfull),每个服务都围绕着具体业务进行构建，并且能够独立的部署到生产环境，类生产环境等，另外，应避免统一的，集中式的服务管理机制，对具体的服务而言，应根据业务上下文，选择合适的语言、工具进行构建 本文参考资料: 尚硅谷周阳Spring Cloud讲解和翻译 ， 业界大牛 马丁.福勒(Martin Fowler)发布的论文 本文若有错误请指正，互相学习，加油! 来源： CSDN 作者： 小小辉先生 链接： https://blog.csdn.net/Modesty_Boy/article/details/104551301

什么是微服务： 简单地说微服务是系统架构上的一种设计风格，他的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自的 进程中进行，服务之间通过HTTP的RESTful API进行通信协作。被拆分的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。 微服务的困境： 1、运维的新挑战 需要维护的进程数增加 2、接口的一致性 拆分了服务，但是业务逻辑的依赖不会消除，需要更加完善的接口和版本管理。 3、分布式的复杂性 比如：网络延迟、分布式事务、异步消息 微服务架构的九大特性： 服务组件化： 组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡硬盘一样，独立且可以更换升级而不影响其他单元。 按业务组织团队 做产品的态度： 每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的形式，以完成开发与交付并将成果交接给维护者为最终目标。 智能端点与哑管道 我们需要粗粒度的通信，在微服务架构中通常会使用这两种服务调用方式： 1、使用HTTP的RESTful API或轻量级的消息发送协议，实现消息传递与服务调用的触发 2、通过轻量级消息总线上传递消息