匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。| 漏洞检测 |
| 隐藏捆绑 |
Android系统架构之微服务架构(2)
微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合）。然而,服务组件粒度过细将导致额外的服务调度,
微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合）。然而,服务组件粒度过细将导致额外的服务调度,这可能会导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的、重量级的面向服务架构。
如果你发现需要从应用内部的用户接口或API层调度服务组件，那么很有可能你服务组件的粒度太细了。同样的，如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。
服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。
共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份，因此违反了DRY规则。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。
提示 : DRY，即don&t repeat yourself.
如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件调度,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。
1.4 注意事项
微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的、单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。
该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末&大爆炸&生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。
最后一个要重视的考虑是，由于微服务架构模式可能是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理、远程系统的可用性、远程访问身份验证和授权等。
1.5 模式分析
下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于其自身特点，基于典型模式实现的能力特性,以及该模式是以什么闻名的。
整体灵活性
整体的灵活性是能够快速响应不断变化的环境。由于服务是独立部署单元,因此变化通常被隔离成单独的服务组件,使得部署变得快捷、简单。同时，使用这种模式构建的应用往往是松耦合的，也有助于促进改变。
每个服务组件都是一个独立的部署单元，使得每个部署单元都相对比较简单，也降低了部署的复杂度。易于部署成为了微服务架构的一大优势。
由于业务功能被分离成独立的应用模块,可以在局部范围内进行测试，这样测试工作就更有针对性。对一个特定的服务组件进行回归测试比对整个单体应用程序进行回归测试更简单、更可行。而且,由于这种模式的服务组件是松散耦合的，从开发角度来看，由一个变化导致应用其他部分也跟着变化的几率很小，也不会出现由于一个微小的变化而对整个应用程序进行测试的蛋疼情况。
虽然你该模式有很多的优势，但由于微服务架构模式的分布式或者跨进程特性，客户程序与服务之间的通信会降低效率，因此它并不适用于高性能的应用程序。
由于应用程序被分为单独的部署单元,每个服务组件可以单独扩展，并允许对应用程序进行扩展调整。例如，股票交易的管理员功能模块可能不需要扩展，因为使用该功能的用户比较有限。但是交易数据请求服务组件可能需要扩展，因为这里每时每刻可能都有无数的人在请求，因此需要较高的扩展性。
由于功能被分隔成不同的服务组件，由于开发范围更小且被隔离，开发变得更简单。程序员在一个服务组件做出一个变化影响其他服务组件的几率是很小的，从而减少开发人员或开发团队之间的协调。
Android中的微服务架构
在Android领域中，我们最常看到的就是如图4-5的Android体系架构。
这是一个典型的分层架构，分为应用层、Framework层、Native层、内核层。这似乎与我们今天要说的微服务架构没有任何关系！大家需要注意的是这是一个更为宏观的架构，在这个分层架构之下还有其他的架构模式，微服务架构就是其中最为明显的一个。Android系统按照职责分为不同的层次，但是在Java层( Java应用程序和应用程序框架)与系统服务层( Android运行环境 )这两个层之间则是通过本地C/S模式进行通信，也就是我们的微服务架构。vcD4NCjxwPs7Sw8fWqrXA1NpBbmRyb2lkz7XNs8b0tq/KsaOstPPWwrvh1rTQ0Mjnz8LLxLK9OjwvcD4NCmluaXS9+LPMxvS2r6O7o7sgU3lzdGVtIFNlcnZlcsb0tq+juyBBbmRyb2lkz7XNs7f+zvHG9Lavo6y9q7f+zvHXorLhtb1TZXJ2aWNlTWFuYWdlctbQo7sgQW5kcm9pZNTL0NC7t76zvajBoqOssqLH0sb0tq9MYXVuY2hlcrPM0PKhow0KPHA+1Nppbml0vfizzMb0tq+686Osu+G199PDaW5pdF9wYXJzZV9jb25maWdfZmlsZbe9t6i94s72aW5pdC5yY87EvP6jrMi7uvO9q2luaXQucmPW0Na4tqi1xMP8we6horf+zvG1yMb0tq/G8MC0oaM8L3A+DQo8cHJlIGNsYXNzPQ=="brush:">
int main(int argc, char **argv)
// 代码省略
// 创建系统文件夹
mkdir(&/dev&, 0755);
mkdir(&/proc&, 0755);
mkdir(&/sys&, 0755);
// 代码省略
// 初始化内核
open_devnull_stdio();
klog_init();
property_init();
process_kernel_cmdline();
// 代码省略
// 解析init.rc文件
init_parse_config_file(&/init.rc&);
// 代码省略
(责任编辑：幽灵学院)
------分隔线----------------------------
今天有空复习了一下Android中AIDL的使用，由于平时开发中使...
在之前的文章深入探究了Handler，我们知道了Android的消息机...
?之前一段时间，我都在研究Android自定义View的相关知识，随...
什么是ViewPager，刚一听到这个词，我们可能感觉很奇怪，但...
Only the original thread that created a view hierarchy c...
在这里写出我们项目中常用的两种弹窗方式,底部弹窗以及中间...
工作日：9:00-21:00
周　六：9:00-18:00
&&扫一扫关注幽灵学院中国领先的IT技术网站
51CTO旗下网站
详述微服务架构的优势与不足
这篇博客是关于如何设计、开发和部署微服务的七篇系列文章中的第一篇。读者将会从中学到方法，并且和单体式架构模式(译者注：本文中会将 Monolithic翻译为单体)进行对比。这一系列文章将描述微服务架构中不同元素。你将了解到微服务架构模式的优缺点，以便决定是否更好的将微服务架构应用到自己的项目中，以及如何应用这一模式。
作者：翻译：杨峰来源：dockerone| 13:44
本文来自Nginx官方博客，是微服务系列文章的第一篇，主要探讨了传统的单体式应用的不足，以及微服务架构的优势与挑战。正如作者所说，微服务架构更适合用于构建复杂的应用，尽管它也有自己的不足。这篇文章作者是Chris Richardson，他是早期基于Java的Amazonite EC2 PaaS平台的创始人。现在他为企业提供如何开发和部署应用的咨询服务。他也经常在http://microservices.io上发表有关微服务的文章。
微服务正在博客、社交媒体讨论组和会议演讲中获得越来越多的关注，在Gartner的2014 Hype Cycle上它的排名非常靠前。同时，软件社区中也有不少持怀疑论者，认为微服务不是什么新东西。Naysayers认为这就是SOA架构的重新包装。然而，尽管存在着不同的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助。
这篇博客是关于如何设计、开发和部署微服务的七篇系列文章中的第一篇。读者将会从中学到方法，并且和单体式架构模式(译者注：本文中会将 Monolithic翻译为单体)进行对比。这一系列文章将描述微服务架构中不同元素。你将了解到微服务架构模式的优缺点，以便决定是否更好的将微服务架构应用到自己的项目中，以及如何应用这一模式。
首先我们看看为什么要考虑使用微服务。
开发单体式应用
假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件，经过初步会议和需求分析，你可能会手动或者使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目，这个新应用将会有一个模块叫：六边形架构 ，架构图如下：
应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。
尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，同样，Rails和Node.js会被打包成层级目录。
这种应用开发风格很常见，因为IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只需要简单运行此应用，用Selenium链接 UI就可以完成端到端测试。单体式应用也易于部署，只需要把打包应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。
单体式应用的不足
不幸的是，这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中，开发团队都会面对新&故事&，然后开发许多新代码。几年后，这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子，我最近和一个开发者讨论，他正在写一个工具，用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是很多开发者经过多年努力开发出来的一个怪物。
一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。另外，团队士气也会走下坡路。如果代码难于理解，就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。
单体式应用也会降低开发速度。应用越大，启动时间会越长。比如，最近的一个调查表明，有时候应用的启动时间居然超过了12分钟。我还听说某些应用需要40分钟启动时间。如果开发者需要经常重启应用，那么大部分时间就要在等待中渡过，生产效率受到极大影响。
另外，复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是每天会改变很多次，而这对于单体式应用模式非常困难。另外，这种变化带来的影响并没有很好的被理解，所以不得不做很多手工测试。那么接下来，持续部署也会很艰难。
单体式应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块完成一个CPU敏感逻辑，应该部署在AWS EC2 Compute Optimized instances，而另外一个内存数据库模块更合适于EC2 Memory-optimized instances。然而，由于这些模块部署在一起，因此不得不在硬件选择上做一个妥协。
单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。
最后，单体式应用使得采用新架构和语言非常困难。比如，设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架，无论是时间还是成本都是非常昂贵的，即使ABC框架更好。因此，这是一个无法逾越的鸿沟。你不得不在最初选择面前低头。
总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，无法理解的怪物。因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。
那么如何应对呢?
微处理架构&&处理复杂事物
许多公司，比如Amazon、eBay和NetFlix，通过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。
一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。
比如，一个前面描述系统可能的分解如下：
每一个应用功能区都使用微服务完成，另外，Web应用会被拆分成一系列简单的Web应用(比如一个对乘客，一个对出租车驾驶员)。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。
每一个后台服务开放一个REST API，许多服务本身也采用了其它服务提供的API。比如，驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。所有服务都是采用异步的，基于消息的通讯。微服务内部机制将会在后续系列中讨论。
一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务，而是通过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务，可以通过NGINX方便实现，后续文章将会介绍到API Gateway。
微服务架构模式在上图中对应于代表可扩展Scale Cube的Y轴，这是一个在《The Art of Scalability》书中描述过的三维扩展模型。另外两个可扩展轴，X轴由负载均衡器后端运行的多个应用副本组成，Z轴是将需求路由到相关服务。
应用基本可以用以上三个维度来表示，Y轴代表将应用分解为微服务。运行时，X轴代表运行多个隐藏在负载均衡器之后的实例，提供吞吐能力。一些应用可能还是用Z轴将服务分区。下面的图演示行程管理服务如何部署在运行于AWS EC2上的Docker上。
运行时，行程管理服务由多个服务实例构成。每一个服务实例都是一个Docker容器。为了保证高可用，这些容器一般都运行在多个云VM上。服务实例前是一层诸如NGINX的负载均衡器，他们负责在各个实例间分发请求。负载均衡器也同时处理其它请求，例如缓存、权限控制、API统计和监控。
这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，但是，如果你想获得微服务带来的好处，每个服务独有一个数据库是必须的，因为这种架构需要这种松耦合。下面的图演示示例应用数据库架构。
每种服务都有自己的数据库，另外，每种服务可以用更适合自己的数据库类型，也被称作多语言一致性架构。比如，驾驶员管理(发现哪个驾驶员更靠近乘客)，必须使用支持跨地域查询的数据库。
表面上看来，微服务架构模式有点像SOA，他们都由多个服务构成。但是，可以从另外一个角度看此问题，微服务架构模式是一个不包含Web服务(WS-)和ESB服务的SOA。微服务应用乐于采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。
微服务架构的好处
微服务架构模式有很多好处。首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。
第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。
微服务架构的不足
Fred Brooks在30年前写道，&there are no silver bullets&，像任何其它科技一样，微服务架构也有不足。其中一个跟他的名字类似，『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。
另外一个主要的不足是，微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务(至少需要这些服务的stubs)。再重申一次，不能低估了采用微服务架构带来的复杂性。
另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。
部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用一般由大批服务构成。例如，根据Adrian Cockcroft，Hailo有160个不同服务构成，NetFlix 有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制(后续文章中发表)，以用来发现与它通讯服务的地址(包括服务器地址和端口)。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。
一种自动化方法是使用PaaS服务，例如Cloud Foundry。 PaaS给开发者提供一个部署和管理微服务的简单方法，它把所有这些问题都打包内置解决了。同时，配置PaaS的系统和网络专家可以采用最佳实践和策略来简化这些问题。另外一个自动部署微服务应用的方法是开发对于你来说最基础的PaaS系统。一个典型的开始点是使用一个集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我们会看看如何基于软件部署方法例如NGINX，可以方便的在微服务层面提供缓存、权限控制、API统计和监控。
构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点和挑战。
在后续的博客中，我会深入探索微服务架构模式，并讨论诸如服务发现、服务部署选择和如何分解一个分布式应用为多个服务的策略。
原文链接：
【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
专题热点热点热点热点
24H热文一周话题本月最赞
讲师：275人学习过
讲师：1542人学习过
讲师：1505人学习过
精选博文论坛热帖下载排行
本书为《Eclipse从入门到精通》一书的全新改版。本书以最新的Eclipse 3.2作为写作版本。全书分为5篇：起步篇介绍了Eclipse及相关插件的安装...
订阅51CTO邮刊大项目微服务架构设计
大项目微服务架构设计
根据目前产品存在的问题，针对快速开发、海量用户、大量数据、低延迟等互联网应用的实际需要，通过对业务架构、架构、基础架构、技术架构进行分析，采用先进实用的微服务SOA架构重构智慧校园、数字化校园等产品，彻底解决系统解耦、性能低下等问题，而且支持云计算部署，可以满足高并发、高可用、高稳定和高安全等性能要求，提供强大的saas和互联网访问服务。由于采用微服务架构，各个服务模块化编写，具有高内聚低耦合的优势，便于灵活更新升级，而不会影响其他业务。一套代码，同时支持移动应用和pc应用，提高效率，节约成本。这个架构还便于AB灰度发布产品，提高开发效率，对测试、运维管理也可以显著提高效率。微服务通过REST方式提供访问,产品实现重构，进行服务划分，可以充分使用现有的代码。.NET产品使用ASP.NETWeb Api提供rest服务，使用RestSharp访问服务；java产品使用restEasy提供rest服务，使用httpClient访问服务。服务实现统一的注册、治理、发现，通过serviceAdapter统一调用。这个架构有助于对外提供访问API，提供open的开发支持，有利于形成公司的产品优势。
这是一个非中心化微服务架构，互联网时代，企业的核心就是效率。传统企业服务总线是中心化的架构，这会导致效率低下、稳定性差，采用去中心化架构，教育显著提高效率，增强安全性和稳定性。采用存储服务信息，采用消息队列处理事务，特点在于多次调用服务，确保成功，采用统一的接口调用服务，对服务进行管理。
这个架构为用户提供的一个核心价值，在于随着系统机器数量的不断增加，处理性能呈线性上升，可靠性呈指数级上升，而运营成本不会随着机器的增加而显著增加。为了实现这个价值，企业级互联网架构呈现了服务化、去中心化、异步化、高可用、数据化运营等五大特征。而且对于开发可以提高效率，产品修改设计方便，测试、运维简单。
服务化的技术体系提供企业级分布式应用框架来实现原有业务面向互联网服务化改造，改变现在的竖井式、烟囱式的系统建设，让应用开发周期更短，并且能够让IT应用系统进一步的促进业务发展。采用去中心化架构，没有核心流量汇入点，这样带来的负载更小，故障影响的范围也更小，能够大幅降低去中心化应用系统的运营成本。
1)没有服务化，各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。
2)应用间数据复制严重，数据不一致性严重
3)基础薄弱，日志，监控系统不完善
4)功能模块定义混乱，包含大量接口，接口定义重复
5)大容量访问下无法提供可靠性服务
6)开发saas互联网功能的产品迫在眉睫，需要满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。
1)核心系统全面服务化：招生、教务、学籍、资产等系统分解为核心服务和基础服务。
2)基础组件：服务化框架，分库分区，缓存组件。
3)加强监控，日志系统。
4)异步化并行，限流，分流，降级，压力测试，异地灾备。
5)数据库统一规划优化。
6)平台和业务功能设计，遵从三个维度定义架构设计的原则：
a. 内容可扩展性
针对智慧校园各个功能提供动态支持。
针对梦想学堂营销活动提供动态可支持性。
b. 功能可扩展性
针对各种扩展功能需求，系统支持统一的方式扩展新的能力，并提供统一的管理。
c. 系统可扩展性
支持对大量用户访问能力的平滑支持。
支持高可用，高安全，并具有高的系统恢复能力。
以基于&云&模式的服务端IT架构框架为整体策略，采用基础架构和功能实现分离的原则：
a. 服务端：构建统一的云模式IT基础设施
基于标准化的设施，分别构建统一的IAAS层和PAAS、SAAS层，实现资源的共享，提高未来业务应用开发的效率和可维护性，并提高整体设备的利用
b. 大架构模式：实现基础架构和功能实现分离原则
功能开发团队
采用简单工具
关注功能实现
关注服务划分和治理
关注数据处理
关注用户体验
系统开发团队
关注系统稳定性
关注系统性能
关注系统扩展性
关注系统可维护性
关注系统可靠性
（1）核心业务抽取出来，作为独立的服务对外服务，实现架构和代码重构。
（2）核心服务调用基础服务，充分复用代码，减少工作量，便于修改维护，把握好服务的粒度划分，过多的服务访问会影响性能，过少会影响灵活性，需要对业务进行细致梳理，合理确定核心服务和基础服务。
（3）服务模块独立部署，充分解耦，各系统灵活使用不同服务，可以独立部署，彻底解决系统耦合不能单独销售问题。
（4）各层彼此独立，修改各层不影响其他层。
（5）数据库读写分离、分库分区
（6）大量使用缓存，提高访问
（7）系统间异步交互
（8）服务对等隔离
（9）移动和pc产品的优化
APP实际上和PC端是对等的，PC端应用有服务端，APP也需要自己独立的服务端，两个服务端都需要针对自身的特点，独立开发，独立部署，同时实现逻辑和物理层面的解耦，从架构层面彻底摆脱PC思维移动化。
1. 统一服务
核心逻辑从Web应用剥离出来，进行服务化改造，服务实现时不区分PC和移动，APP和Web应用都依赖于这些服务，一套接口，多方调用。
2. 统一网关入口
提供统一的移动网关，所有APP调用指向此网关，网关包括通用层、接口路由层、适配层。
通讯协议适配、数据封装、安全、监控、日志这些系统级功能，每个接口调用都需要同样逻辑，这些功能统一由网关前置处理，避免重复开发。具体实现时，每个通用处理逻辑封装成拦截器，遵循统一的过滤接口，并且做到可配置，网关依次调用这些拦截器，这样可以支持通用逻辑的灵活扩展。
拦截器接口定义如下：
Object filter(Object input) throws Exception
经过通用逻辑预处理后，移动接口请求将进一步分发给后端处理（各个Adapter）。URL和Adapter在配置文件里做映射，分发逻辑根据请求中的URL信息，找到对应的Adapter，然后把请求交给Adapter处理。
配置例子如下：
/search SearchAdapter
/detail DetailAdapter
4.服务适配
外部移动接口和内部SOA接口的输入输出格式以及通信协议很可能不一样，比如前者经常是HTTP+JSON格式，后者可能是Hessian+二进制格式，Adapter首先用于移动接口和内部SOA接口的适配，除此之外，Adapter还可能对多个SOA服务做聚合，对APP提供粗粒度的数据，以减少远程网络调用次数。实现上一般每个业务系统有一个Adapter，负责本系统移动接口的调用适配。
Adapter接口定义如下：
Object adapter(Object input) throws Exception
Adapter物理上是jar包，由各个业务线研发团队提供，作为相应SOA服务的前置，最终所有Adapter集中部署在网关，网关本身支持水平扩展。
（10）关键点：
1.服务注册中心，zookeeper集群作为分布式调度中心，各个服务注册在zookeeper之上，注册内容包括服务的请求url，请求ip地址和端口，服务组件名称，注册时间等；
2.Gateway，服务网关作为系统的入口，具有服务转发、授权验证、负载均衡等作用，可以使用高并发框架netty实现高速转发等；
3.访问控制服务，用户首先需要获得系统授权才可以访问业务服务，授权通过token来实现；
4.业务服务1~N，是系统内具体业务组件的划分区别核心服务和基础服务；
5.数据服务，实现信息的修改、共享等；
6.配置中心，整个系统的配置均位于配置中心，组件通过访问配置中心获取配置参数；
7.监控系统，检测服务、redis、zookeeper集群等的各项状态，自动告警和智能调节服务，防止服务器雪崩；
8. 消息队列系统，支撑全部系统；
9.服务治理、发现、调用。
10.服务调用通过serviceAdapter接口完成。
1. 通过重构智慧校园架构，完成原有功能及新增功能。架构分为应用层、核心服务层、基础服务层、资源层及ecloud层。
2. 应用层主要实现与Web页面、移动客户端的接口交互。
3. 服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为基础服务，定义是不依赖任何其他服务的服务模块，表示它们的独立性，另外一类为核心服务，通过各种原子服务和业务逻辑的组合，完成的Composite服务，定义统一的接口规范访问。
4. 资源层主要是数据和文件的存储，包含通用的缓存资源Redis以及持久化数据库存储MySQL、HBase，及分布式文件系统TFS等。
5. 水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。
6.Ecloud层提供一门户、单点登录、用户权限管理中心、统一数据中心、统一认证中心、运维管理中心、消息推送中心、配置管理中心、统一注册及验证、统一注销、报表服务、统一会话、元数据、日志、缓存及通用基础功能等功能。产品的上层服务层调用ecloud的功能，统一代码，充分复用，便于修改。
l系统中需要同时满足移动端产品以及pc产品的需求。
l 系统需要支持高性能、高并发性、高可用性的设计实现方案。
l 安全性：应保证系统中关键敏感信息的安全性，包括但不限于用户名密码凭证、Ticket信息等。
l 支持5千万人在线，大部分页面同时最多5000个并发请求，事务成功率不低于98%。
l 系统保证7*24 小时运行，稳定可靠；
l 平均延时：普通页面，小于2秒，最大不超过5秒；查询页面，小于3秒，最大不超过17秒；
l 支持负载均衡、可扩展性。
l 运维自动化，实时监控系统，及时发现异常和故障并自动告警。
l 系统故障恢复时间不超过1小时。
这个基础平台以先进的教育教学理念和技术作为依撑，以&应用导向&为基本原则，以探究教育教学的本质为主要精神，以教学资源整合为重要手段，以教学资源的开放共享为扩展方向，实现教育教学与IT技术的深度融合，采用微服务架构实现一个共享可复用的统一框架，是具有扩展性、兼容性、前瞻性的底层平台，实现6大产品共享，满足快速开发、避免重复开发的需求，开创产品创新的新模式和新途径，更好的为产品开发和部署、运维提供服务。
l 平台共享数据为各个子系统共同调用的数据，减少各子系统间数据的调用，减少系统间的耦合性，达到&强内聚，低耦合&的效果；
l 可实现数据一次输入，多个子系统使用，消除信息孤岛，减少数据库服务器工作量，提高整体使用性能；
l 提供统一的开发框架，提高开发效率，避免重复开发，节约成本；
l 便于部署，实施和运维；
l 整合6大平台，形成强大的合力。
l 形成一个产品，用于教育、金融等产品的开发和管理。
l 服务模块化设计，便于根据需求组合使用。
l 服务统一注册、发现、治理。
l 便于集群部署和负载均衡，提供强大的并发支持和高可用。
a)系统稳定、高效，可支持校园内外各种不同使用场景下的并发操作。
b)系统有良好的扩展性：在增加新的功能时旧有模块不做改动或稍作改动即可完成集成，部署更新不影响其他业务。
c)提供数据接口：便于其他产品或第三方厂商系统进行集成。
d)模块化：各个功能部分按模块开发，模块彼此解耦。
e)配置化：可根据客户实际需求，配置不同参数。
f）支持6大平台的开发和运行，支持Windows和系统。
g） 采用B/S架构，与外部业务系统之间使用RestfulAPI进行交互，使用Spring MVC、java、语言进行开发。
h)需要支持高性能、高并发、高可用和高稳定的需求。
信息标准建设是数字化校园建设的重点之一，对推进数字化校园建设，保证 信息的交流与共享，有着重要的意义。鉴于各个学校的特殊性，因此所采用的信息标准必须保证和国家以及教育部的信息标准相兼容。
《教育管理信息化标准》的颁布为教育部门进行教育数据总体的规划和组织，建立统一的数据平台提供明确的规范和标准，它将带动教育管理信息存储、访问、更新、传递方式的变革，进一步减轻学校人力资源和财政管理的负担。
根据上述信息标准的要求，本公司将结合国家和行业标准以及学校的实际要求，制定出《学校信息化数据标准》。该数据标准在全校范围内作为数据编码的依据和标准，为提供了类似数据字典的作用，为信息交换、资源共享提供了基础性条件。
标准制定的实施过程如下图所示：
制定完成后的高校信息标准有以下内容，如图所示：
l 系统采用B/S架构，需要使用spring MVC、java、c#语言进行开发，提供RestfulAPI和其他系统进行集成和交互。
l java系统采用java技术构建，应用服务器仅支持部署在Windows +tomcat8平台，但并不限定使用Ecloud系统服务的其他相关系统的操作系统平台,.net系统使用c#开发。
l 系统功能需要支持高性能、高并发性、高可用性的方案。
l SRP（Single Responseble Principle）即单一职责原则，每一个服务提供者仅暴露自己职责范围内的接口，操作职责范围内的DB，不继承其他服务提供者的协议。简单点说，该你干的才去干，不该干的调用其他人的服务来干。
lRESTful，作为Web Service的替代者，其面向资源的特性注定是为微服务而生的，接口设计符合REST设计原则将使服务易于理解和接受。需要注意的是，灵活的使用，如保持请求风格一致，一般用GET/POST，少用DELETE/PUT，保证同类资源前缀的一致性等。
l 分离关注点，将应用划分为在功能上尽可能不重复的功能点。主要的参考因素就是最小化交互，高内聚、低耦合。但是，错误的分离功能边界，可能会导致功能之间的高耦合性和复杂性，
l 最小知识原则，一个组件或者是对象不应该知道其他组件或者对象的内部实现细节。
l 不要重复你自己，你只需要在一个地方描述目的。例如，特殊的功能只能在一个组件中实现，在其他的组件中不应该有副本。
l 最小化预先设计，只设计必须的内容。在一些情况，你可能需要预先设计一些内容。另外一些情况，尤其对于敏捷开发，你可以避免设计过度。如果你的应用需求是不清晰的，最好不要做大量的预先设计。
l 高内聚低耦合：将不同的功能代码分离开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元，十分有利于系统的维护和扩展。新增的自定义公式必须符合该原则。
l 可视作一个独立的系统，为减少重复的开发、统一管理，提高整体开发效率而存在。
基础平台应具有良好的开放性和兼容性，采用面向服务的公共管理平台，提供REST API接口，通过统一信息门户、统一权限管理和公共数据交换，整合、集成各类应用系统和各种信息资源，实现资源和平台的开放共享。
基础平台整体建设采用先进的理念和思想、成熟的技术与设计方法，符合当前潮流与未来发展趋势，以便跟上信息技术的发展，具有较强的生命力，具有长期使用价值。
基础平台建设的核心目的就是&易用&，须坚持易用的设计原则，紧紧围绕开发的实际需求，在满足产品要求的前提下，以尽可能少的投入，取得尽可能大的效益。
基础平台支撑着整个系统的日常管理、教学、生活、科研、文化、服务、信息安全和资源建设等方方面面，必须具有高可靠性、高容错性和强大的数据处理能力，使用成熟的热备份技术和集群技术，以确保不间断运行、确保局部出错不影响整体、确保快速响应。
基础平台必须具有良好的稳定性，保证持续运行时间长、故障间隔大、无故障时间长。
6、可扩展性
基础平台必须具有良好的可扩展性，对于校园管理模式的变化、管理体系的调整、业务流程的改变等，能够通过规则引擎简便配置即可快速适应变化，满足学院的需求。
7、易升级性
基础平台采用版本控制机制与更新包技术，能够简便快捷地完成整体或部分的版本升级。
8、易维护性
基础平台的用户包括部门的管理人员、工程师，必须坚持易维护的设计原则，确保结构清晰、界面友好、操作简单、维护方便。
构建全方位、多层次、完善的安全保障体系，通过安全制度建设和安全教育，在保证物理安全和的基础上，保证数据安全。根据基础架构及各个软件系统的设计要求，采取不同的安全策略与安全措施，保证。
基础平台通过身份认证、角色定义与权限分配，确保每个用户能且只能访问相应的信息资源与应用服务。
11．可管理性
基础平台具有高度可管理性，使得开发人员的开发简便快捷。
12． 逐步完善，平滑过渡
要根据现有的产品情况，逐步开发实施，平滑过渡。
13．遵照 SOA 的设计理念，建立松散耦合的集成与应用
14．可持续建设
平台在满足现在开发需求的同时，能够兼顾公司的发展现状，设计一套能够满足未来一段时间发展的标准，并且在全局建设过程中能够持续的升级、维护标准。
15．服务组件及中间件一体化、通用化。
系统采用4层微服务架构，分别是展示层、应用层、服务层、数据资源层。
按照&高内聚，低耦合&的思想，将不同的功能代码分离开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元，十分有利于系统的维护和扩展。系统采用微服务架构，分5层，分别是分别是展示层、应用层、服务层、数据资源层、ecloud层。
Ecloud系统中，管理系统的实现技术类似，通过各个分层之间的协作来实现增删改查。下图以角色管理的增加功能为例说明各个分层之间的协作机制。
1. 用户通过Management UI增加角色页面一个角色，Management UI调用应用层Role Business的Add方法，同时把接收到Model实体对象传递到过去。
2. RoleBusiness层调用核心服务层和基础服务层服务，同时把Model实体对象传递到过去，进行处理。
3. RoleID逐层返回给Management UI。
重要设计包和端口
项目的包名和类名需要规范化，按照统一的约定完成。
com.xx.platform.cache
缓存组件包，包含缓存相关类。属于公司级的公共组件
Ecloud项目的公共功能类
com.xx.platform.dto
显示业务实体类
com.xx.platform.vo
持久化实体类
com.xx.platform.dao
数据访问层
com.xx.platform.service
服务逻辑层
com.xx.platform.controller
业务逻辑接口层组件，应用真实的业务逻辑类
com.xx.platform.exception
系统的异常类
com.xx.platform.interceptor
com.xx.platform.utils
系统的工具类
com.xx. platform.configuration
系统的配置类
1. Dao类分为接口XXDao和实现类XXDaoImpl及数据库映射文件XXDao.xml。
2.Service类分为接口XXService和实现类XXServiceImpl。Service分核心服务和基础服务。
3.Controller类继承基类BaseBiz。
4.Vo和Dto类继承基类BaseVO， Dto面向页面和业务处理，Vo面向持久化。
PageModel类为分页类。
5.前端页面采用freemarker生成html，简单高效。
6. Exception 类继承基类BaseException。
7.尽量减少端口，充分复用现有端口。
采用java和.NET开发，部署在tomcat8和iis上，
产品使用先进实用稳定可靠的jdk1.8+spring4+mybtis3+jquery1.9.1+freemarker-2.3.21+5.6框架。支持ie8+、firefox、chorme浏览器，使用restEasy提供REST服务；.NET产品使用visiostudio开发。
系统理想的网络部署图如上所示。需要说明的是：
1. 应用服务器、CAS服务器、service服务器、管理服务器、数据库服务器部署在一个局域网内部。
2. 数据库系统采用主从结构，保证高可用性。
3. CAS服务器负责单点登录功能，需要保证高可用性，因此至少需要部署包含两台服务器的集群。
4. 管理服务器作为部署Management UI的WEB服务器，通常情况下部署一台服务器即可。
5. 系统管理员、用户通过Internet与分别与管理服务器、应用服务器链接。
6. 为了提供数据访问的性能，需要部署缓存系统Redis。
7. 采用docker、k8s部署到容器，实现集群的自动负载均衡和管理，提高性能和稳定性，简化运维。
软件到硬件的映射
l 应用服务器：运行业务系统。WindowsServer 2013、iis+tomcat8
l service服务器：运行服务系统。WindowsServer 2013、iis+tomcat8
l 管理服务器：运行管理系统。WindowsServer 2013、tomcat8
l 数据库服务器：运行数据库系统。Linux、MySQL5.6、Redis3。
l 缓存服务器：运行Redis系统。Linux、Redis3。
为了减少硬件的成本，可以把管理系统部署在应用服务器上，省去管理服务器。各个模块可以分别部署，便于灵活修改升级发布。Service服务器可以根据访问量进行集群和负载均衡。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'