新名词-微服务

“微服务”架构是近期软件应用领域很是热门的概念。那什么是微服务？

简单的说，微服务架构就是将一个完整的应用 从数据存储开始垂直拆分红多个不一样的服务，每一个服务都能独立部署、独立维护、独立扩展，服务与服务间经过诸如REST、API的方式互相调用。

传统IT架构面临的一些问题以及云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟 ，这就催生了新的架构设计风格 – 微服务架构的出现。

（简单描述一下轻量级技术涌现：

 一、轻量级运行时技术的出现(node.js等)；

 二、新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；

 三、新的轻量级协议(RESTful API接口, 轻量级消息机制)；

 四、服务平台化(PaaS)： 云服务平台上具备自动缩放、工做负载管理、SLA 管理、消息机制、缓存、构建管理等各类按需使用的服务；

 五、标准化代码管理：如Github等；）

微服务架构的优势：

1. 每一个服务都比较简单，只关注于一个业务功能。

2. 微服务架构方式是松耦合的，能够提供更高的灵活性。

3. 微服务可经过最佳及最合适的不一样的编程语言与工具进行开发，可以作到有的放矢地解决针对性问题。

4. 每一个微服务可由不一样团队独立开发，互不影响，加快推出市场的速度。

5. 微服务架构是持续交付(CD)的巨大推进力，容许在频繁发布不一样服务的同时保持系统其余部分的可用性和稳定性。

微服务架构的缺点：

     微服务的一些想法在实践上是好的，但当总体实现时也会呈现出其复杂性。

1. 运维开销及成本增长：总体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成须要构建/测试/部署/运行数十个独立的服务，并可能须要支持多种语言和环境。这致使一个总体式系统若是由20个微服务组成，可能须要40~60个进程。

2. 必须有坚实的DevOps开发运维一体化技能：开发人员须要熟知运维与投产环境，开发人员也须要掌握必要的数据存储技术如NoSQL，具备较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。

3. 隐式接口及接口匹配问题：把系统分为多个协做组件后会产生新的接口，这意味着简单的交叉变化可能须要改变许多组件，并需协调一块儿发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，因为集成点的大量增长，微服务架构会有更高的发布风险。

4. 代码重复：某些底层功能须要被多个服务所用，为了不将“同步耦合引入到系统中”，有时须要向不一样服务添加一些代码，这就会致使代码重复。

5. 分布式系统的复杂性：做为一种分布式系统，微服务引入了复杂性和其余若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差别化的工做负载等，开发人员须要考虑以上的分布式系统问题。

6. 异步机制：微服务每每使用异步编程、消息与并行机制，若是应用存在跨微服务的事务性处理，其实现机制会变得复杂化。

7. 可测性的挑战：在动态环境下服务间的交互会产生很是微妙的行为，难以可视化及全面测试。经典微服务每每不过重视测试，更多的是经过监控发现生产环境的异常，进而快速回滚或采起其余必要的行动。但对于特别在乎风险规避监管或投产环境错误会产生显著影响的场景下须要特别注意。

   关于微服务架构的取舍：

1. 在合适的项目，合适的团队，采用微服务架构收益会大于成本。

2. 微服务架构有不少吸引人的地方，但在拥抱微服务以前，也须要认清它所带来的挑战。

3. 须要避免为了“微服务”而“微服务”。

4. 微服务架构引入策略 – 对传统企业而言，开始时能够考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

如今在业界基于微服务的实践方法有两种，一种是dubbo，一种是springcloud

未完，待续。。。。