微服务具备的特性：每个微服务都可以运行在自己的进程里；一系列独立运行的微服务共同构建起了整个系统；每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如订单管理，用户管理等；微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用 

微服务带来的挑战：运维要求高，分布式的复杂性增加，接口调整成本高，重复劳动

微服务的设计原则：单一职责，服务自治，轻量级通信，接口明确

 

单体（Monnoliths）架构：

App:可能是网站，可能是app

单体应用的功能是由在一个处理流程里以库(libera)为元件组成的（java的jar包）。

缺点：

开发的问题：所有东西都在一个project，project编译构建可能要一两个小时，对做持续整合和持续部署的效率是伤害。

扩展的问题：流量负载加大时，应对措施只能扩展整个app，机器资源利率很糟。

比如：A元件吃cpu，B元件吃io，但是他们绑在一起，在跑A元件的时候，cpu很忙，而 io 和memory很闲，硬件资源的使用率就很浪费糟。

 

微服务(Microservices)架构

把一个庞大的application拆成几个小的独立的服务，再把独立的服务串起来。

优点：

不用再维护一个很大的project，只给维护一些小的project。It的部门在部署的时候，就会有更多的弹性。可以有效的安排这些服务的安装。

扩展：系统的瓶颈（可能耗cpu，内存，io）假如是A服务，要扩展，就可以只按需求只扩展A服务

微服务架构的缺点：

微服务把单体开发的复杂度简化了，但部署和服务跟服务之间的复杂度会提高，所以需要有一个对architect层面比较清楚的人来做规划。

 

微服务架构拆分出来的服务，可能有的有状态，有的没有状态，没有状态是最理想的。

有状态服务，应该把服务和它的数据放在一起处理。提前规划好，后面就可以比较方便的拆开。

 

开发方式，security，model和架构设计要改。甚至连It部署和管理的方式都要改。

 

 

为什么要采用微服务的方法？

Build and operate a service at scale

可以持续的进化应用，可以在单独的服务里引进适合自己的技术。比如，在以java为主的系统中，可以在某些服务采用c#开发。

Improved resource utilization to reducecosts

可以改善资源利用，节省成本。

错误隔离。Fault isolation.

Continuous innovation持续演进

团队的关注点更小(small focused team)

Canbe written in any language and framework

 

Autonomous service 自主式的服务

Encapseulates a scenario

Oraganized around business capabilities

Contain code plus state

Independently versioned,deployed,and scaled

Interactwith other microservices over well defined interfaces

Uses protocols such as http

Hav a unique name(url) that can resolved

Remains consistent and available in the presence of failures

 

微服务的核心：

为什么要有微服务，现状，痛点：

你能做到每周每天甚至每个钟头，向客户，发布新特性吗?新加入的开发者，都能够在他们工作的第一天，甚至面试阶段就能部署代码吗？部署新员工的代码，你能因为确信应用程序运行正常而安然入睡吗？

 

解决方案：

建立快速发布机制，包括支持cloud-native应用的安全与可靠的运维的流程，工具和文化。已经成为软件驱动组织的关键，战略因素。有了快速的发布机制，这些组织就能在降低风险的同时，更加快速的发布软件，发布软件越快得到的反馈循环就越紧密，企业就能更有效的响应客户的需要。

 

成功微服务的要点：

持续交付是软件正在变成，cloud-native应用的原因。更快的交付软件，降低反馈循环的时间。完全实现战略，需要文化和技术两方面的改变，devops是应对这些改变的方法。微服务是应用最成功的软件体系架构模式，它扩展了，开发和交付操作。避免缓慢充满风险的，单体，部署策略，例如，如果没有建立快速失败和，自动优先的，devops文化，很难成功的实施微服务战略。

 

Cloud Native的五个层面：

1. 康威定律：业务云化推行，从某种意义上讲也是一种变革。

2．Devops：是一组过程，方法与系统的统称，用于促进开发，应用程序，软件工程，运维和质量保障部门(QA)之间的沟通协作与整合，

3．持续交互(continuousdelivery): 是一系列的，开发实践方法，用来确保让代码能够快速，安全的部署到产品环境中，它通过每一次改动，都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。

4．微服务: 微服务首先是一个服务，其次该服务的颗粒比较小，微服务可以采用多克，等技术手段实现

5．敏捷基础设施(agile infrastructure)：提供弹性，按需的计算，存储，网络资源能力。

 

 

 

 

组件之间耦合越松，越能扩展到极限。

Developer（开发人员）顾好自己的元件。

Architect（架构人员）负责元件之间的解耦。

Operator（运维人员）负责扩展。

 

 

 

Design&development  

 infra for microservices   architecture refactoring

API Dev(conract)(impl)(dev-process)

Database partition (sharding,partition)

Use other third party services

Deployment&operation

 

Monitoring,logging,tracking

Containerize

Scalability

Container orchestration management

 

 

小结和讨论

微服务，强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100LOC服务组，尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。

 

定义什么是微服务

能独立自主动作（独立布署，升级维护，改写）

包含程序(code)的执行，与状态（state）

微服务之间，必须透过定义好的界面沟通

单一服务发生故障，系统仍能保持一致性与可用性

 

为什么要采用“微服务架构”？

          小巧，并且专注做好一件事

确保系统架构的扩展性，不会成为将来营运的瓶颈

提升资源的使用率，降低营运成本

故障隔离，单一服务失败可能降级功能，而不是整个系统挂掉

让数个小型团队，各别负责服务的开发与维护

持续创新，每个服务可以允许使用不同的开发技能与框架（可用最佳的技术开发，或是挑战最佳的服务）

 

架构师：如何将系统改为微服务架构的步骤？

检视现有的系统，定义服务的边界，分割为数个独立动作的服务

系统扩充的三个面向（依这样的需求切割服务）：

复制同样的服务（scale by cloning）

垂直分割（functional decomposition）

水平分割（splitting similar things）

 

通过基础服务自动化工具，来管理及部署服务

Infrastructure as code

采用“不可变的server”(immutable servers)来部署服务

采用container orchestration tools来管理服务

 

微服务部署：使用容器技术（container）

 

 

用统一规格，封装微服务，统一部署管理。

(infrastructure as code)

   Containerimage 被产生（Build）之后，统一放到储存库(Push to register), 部署时可以直接取用（Pull&Run）

  将application封装成Container images只允许这些操作:
控制能使用的运算资源(CPU,Memory)

控制网路连接(port mapping , containerLinks)

控制资料的存储(volumes)

控制环境变量(environment variables)

控制(Container)的执行状态(start/stop/pause/continue)

Container被产生之后就不允许修改，已部署的服务若要启动,唯一的方式是重新build>ship>runs

 

Benefits from docker

1.Solve “works on my machine” syndrome

2.security

3.faster time to market with microservices

4.unlock the ecosystem

5.”developed in the open”

 

Immutable Server

What is “just enough” concept?

实操上可能的难题

维护困难：大型单体式开发，维护，更新，调试都很困难，改一行代码就要测试所有功能

扩充困难：由于服务无法分割，只能整体进行扩充，复杂度高，系统失败也会导致整个app pool failure,无法隔离application内有部分元件failure

云端化困难：难以朝向云端化发展（我们想将部分服务切割出来，改由原来直接从云端提供服务），同时系统非多租户设计，要大量部署同样服务给不周客户的效率及使用率也不佳。

改版的步骤

切割：找出系统的边界，挑出适合切割出独立的微服务区块

界面：定义api，protocal,对应的sdk，版本相容性与安全性原则

架构安全：服务之间的安全机制，采用授权token,json+数位签章（AES）

 

框架：决定服务要采用的开发技术，框架，执行环境

重构：用重构+单元测试，逐步改善原本的系统架构，切割出独立服务

测试：部署容易，可局部更新，可随时使用真实的环境测试

追踪：规划统一的log机制，按操作序号追踪，解决跨服务问题排除

监控：服务动作状况，服务效能表达=现，服务失败后的治理原则

压测：了解单一服务效能瓶颈，与运作规模的上限