小团队

待做的： 学习框架：nameko、double、spring cloud、书 微服务的定义： 一些协同工作的小而自治的服务 微服务的核心思想： 1.自治： 1）每个微服务（APP）可以独立部署到PAAS（platform as a service）上 2）作为服务方，需要避免方暴露过多给消费而产生耦合，从而降低服务的自治性。要封装好，服务方内部实现修改，不该影响到消费方。 2.细粒度： 1）解耦：避免系统臃肿、难以维护 2）内聚性：相同的东西放在一起 3.隔离性： 1）各服务直接均通过网络调用进行通信（而不是代码调用），避免了紧耦合 2）各服务之间通过API调用，API解耦性必须要好，以保证技术的选择不被限制 3）一个黄金法则：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？（独立部署） 微服务的优点： 1.细粒度-》扩展性好-》可以快速响应变化、快速交付-》可以尝试更多的新技术 2.增加了团队的自治力 3.技术异构性。可以根据不同的业务场景，选择不同的技术，来构架服务。比如某个APP对性能有特别高的要求。或者某些APP对底层数据库有特别的要求（图数据库、文档数据库、关系型数据库）。这点需要APP足够小，可以快速重写，从而降低风险。还有就是框架要支持多语言开发业务模块。 4.弹性（稳定性、可用性）：第11章，详解 5.扩展：可以很容易把独立的服务，分割出去独立部署

SpringCloud学习 微服务介绍 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一一个的服务，彻底， 地去耦合每一个微服务提供单个业务功能的服务，一个服务做一-件事, 从技术角度看就是一种小而独立的处理过程，类似进程概能够自行单独启动 或销毁，拥有自己独立的数据库。 微服务与微服务架构 微服务 强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用, 狭意的看,可以看作Eclipse里面的一个个微服务工程/或者Module 微服务架构 微服务架构是⼀种架构模式，它提倡将单⼀应⽤程序划分成⼀组⼩的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。每个服务运⾏在其独⽴的进程中，服务与服务间采⽤轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进⾏构建，并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外，应当尽量避免统⼀的、集中式的服务管理机制，对具体的⼀个服务⽽⾔，应根据业务上下⽂，选择合适的语⾔、⼯具对其进⾏构建。 微服务优缺点 优点 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求 开发简单、开发效率提高，一个服务可能就是专一的只干一件事。 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。 微服务是松耦合的，是有功能意义的服务

上周六参加了一场由淘宝的架构师，曾宪杰先生主讲的淘宝网架构分享。然后马上就出差了，一直没来得及总结，今晚比较有空，把这次听到的比较有启发的观点记录一下 一、为什么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

2020年春节，是个难忘的假期，举国抗击新肺炎，不能出门，正好利用这段时间在家看书学习。以下是《赋能：打造应对不确定性的敏捷团队》读书笔记，分享给大家。 一、应对不确定性 1.1 不确定性已经显现 再强大的优势也会有失去掌控的时候； 由小团队组成大组织，并且进行决策权力的“去中心化”，给小团队赋能敏捷； 在无序中寻找关系，制定好的计划往往与实际面临的情况不同，需要在执行和实践过程中寻找规律； 环境因素在不断变化，我们的管理方式需要创新；在其所统领的组织中培育一种文化，让组织中所有的个体都有主动性，并且能够进行关键性的思考，同时反对简单地执行命令。 1.2 还原论的时代与全新的时代 新世界需要重写游戏规则。为了取胜，我们不得不将传统的经验教训放到一边，并且抛弃长久以来为了优化效率而学到的东西。因为我们所面对的新挑战无法想象，新世界与旧世界之间的区别是一条鸿沟，我们需要根据实际情况调整我们行动的标准流程，适应时代的发展。 1.3 从复杂到错综复杂 复杂的事物或许有多个部分，这些部分以比较简单的方式彼此连接、彼此相依。而“错综复杂”是在多个元素间的互动剧烈增加的情况下发生的——万物的关联性使得病毒和银行倒闭的影响能够扩散，就这样，事物迅速变得无法预测。 “复杂”与“错综复杂”之间，很难或者说不可能画出一条明确的界线来。 错综复杂的环境需要新的管理方法

优点 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求 开发简单、开发效率提高，一个服务可能就是专一的只干一件事。 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 微服务能使用不同的语言开发。 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。 微服务允许你利用融合最新技术。 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库 缺点 开发人员要处理分布式系统的复杂性（分布式的通讯和事务的控制） 多服务运维难度，随着服务的增加，运维的压力也在增大（以前部署一个war 包 现在可能是上百个监控上百个看到底谁出问题） 系统部署依赖（一个调不通，其它的需要调用这个服务的服务就不爽） 服务间通信成本（以前是1 ，现在可能是10、100 服务与服务之间调用超时、调不通） 数据一致性 来源： CSDN 作者： weixin_45741427 链接： https://blog.csdn.net/weixin

在公司学习了接近一个月。 一个月内，从0开始开始接触分布式微服务架构，给了我不小的收获。今天，我来从头到尾梳理一下，有关微服务架构的核心内容（全是干货）。 下文，你将看到业界主流微服务框架的核心原理，包括服务发现，网关，配置中心，监控等组件，功能和架构原理的简单介绍。感谢阅读！ Hello，Microservices 什么是微服务 微服务Microservices之父，马丁.福勒，对微服务大概的概述如下： 就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。但通在其常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。 根据马丁

所有的经济调整期，同时也是进行人才调整的好机会。而在这场人才调整中，苏宁已取得先机。 作者 | 薄冬梅 编辑 | 刘 煜 领导者的责任是什么？美国通用电气前CEO杰克·韦尔奇的答案是“寻找最好的员工”。 “我观念中的领导艺术是什么？”他回答道，“它只是跟人有关，只是要最优秀的员工。没有最好的运动员，你就不会有最好的体操队、排球队或橄榄球队。” 将人力资本放在发展首位的苏宁，显然懂得领导的艺术。张近东曾提出了“敬业、专业、事业”的用人三原则，想找到敬业、专业，把工作当成事业来做的事业经理人。 当前零售行业正在经受着深刻的变革，在电商倡导数年的价格效率提升之后，全行业迎来了价值效率提升。而价值效率的提升与人，尤其是消费者的体验有关，与技术相比，这场变革的主角显然是“人”——可以说，这同时也是有关“人”的效率提升，毕竟只有人了解人，也只有人能够知道怎么让企业更好地服务人。 站在2020年的重要关口，在内部将“人”放在首位的苏宁，也将自己对“人”的理解向外释放出来。它在人才的激励与任用上，有着怎样前沿的思考与探索？ 01 “一次表彰大会” 1月21日，一年一度的苏宁表彰大会上，牛铁生收获颇丰。 “我到现在都还记得我第一家店开业，两天的销售额就几乎把一整年的租金都赚回来了。”站在领奖台上，他难掩激动。 牛铁生获优秀合作伙伴 两年前，在传统手机零售业摸爬滚打20年的他

[ 亿欧导读 ] 2018年底到2019年年初，随着阿里、腾讯、百度等巨头的大规模组织架构调整，中台的热度陡增。一时间，各大互联网公司纷纷开始跟随建设中台。那么什么是中台，我们来快速梳理一下中台的相关知识。 ​ ​ 本文转载自msup，作者msup，原文链接：https://mp.weixin.qq.com/s/aNnnTIwx_ZPDYaopW-mD8w 2018年底到2019年年初，随着阿里、腾讯、百度等巨头的大规模组织架构调整， 中台 的热度陡增。一时间，各大互联网公司纷纷开始跟随建设中台。 今年5月2日，有消息传出称阿里正在拆分“大中台”模式。随后，阿里回应称此消息为假消息——这一回应也进一步催生了”中台“架构思想的火热讨论。那么什么是中台，我们来快速梳理一下中台的相关知识。 一、什么是中台？ 按照数据咨询公司Thoughtworks首席咨询师王健给出的10个字定义，中台就是： “企业级的能力复用平台” “企业级”划定了中台的范围，区分开了单系统的服务化与微服务。 “能力”指定了中台的主要承载对象，能力的抽象解释了各种各样中台的存在。 “复用”定义了中台的核心价值，过去的平台化对于易复用性并没有给予足够关注。中台的兴起，使得人们的目光更多的从平台内部，转换到平台对于前台业务的支撑上。 “平台”说明了中台的主要形式，区别于应用系统拼凑的方式

大数据文摘出品 对大多数企业来说，即将收官的2019年是艰难的一年。 全球经济增长同步趋缓，增量市场转变为存量市场，传统企业急需一种方式寻求转型升级的新动力，进一步拓展市场。 随着大数据、云计算、人工智能等技术的发展，数字化转型成为了不少传统企业的“救命稻草”。各种企业数字化转型的解决方案也随之应声而出。比如今年大火的“中台”，已经成为to B企业口中的“新热词”，大有成为企业数字化转型标配的趋势。 然而，企业数字化转型建个中台就够了吗？ “中台并非需求本身，更不是企业数字化转型的全部。”对于这个问题，滴普科技董事长兼CEO赵杰辉有明确的答案。作为一家成立不到两年的初创企业，滴普科技致力于为企业提供数字化智能平台全栈服务，短时间内已获得3轮融资、超4亿人民币。目前，滴普已经为40+大中型企业提供了数字化服务。近日，我们也与滴普科技创始人赵杰辉聊了聊他眼中的数字化转型和数字中台。 中台概念是怎么火起来的？ 2019是to B市场热词频出的一年：腾讯的产业互联网、阿里提出的中台、云原生、PaaS、Serverless，世界产品经理大会上，华为又提出了云产品模式。 其中最广为人知的当属“中台”概念，然而今年5月份之前，中台这个词甚至没有被百度指数收录，7月份之前，关注度也不如PaaS、产业互联网这些词高。 其实最早推广“中台”这个概念的公司还不是阿里，文摘菌追溯了一把，类似“中台

【架构-01】转载：微服务架构 纯洁的微笑公众号文章：【12张手绘图】我搞懂了微服务架构！ 什么是微服务？ 微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。 每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。 另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。 可以使用不同的语言来编写服务，也可以使用不同的数据存储。 根据马丁.福勒的描述，我总结了以下几点： ①小服务 小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。 ②进程独立 每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整个服务。 ③通信 过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and dumb pipes。 这些 Endpoint 都是解耦的